Re: Draft Blog Post on Cryptography API

On Mon, Oct 8, 2012 at 10:22 AM, Harry Halpin <hhalpin@w3.org> wrote:
> As promised, here's a draft blog post to respond to some of the comments,
> and I'd like the WG to look at it before publishing on the W3C blog. Please
> feel free to make additions/subtractions/corrections. Note the provocative
> title :)
>
>   -harry
>
> ----
> Title: Re-igniting the Javscript Cryptography Flame War
>
> Recently, the W3C has released as a First Public Working Draft the Web
> Cryptography API [1], which defines a number of cryptographic primitives to
> be deployed across browsers and native Javascript environments. As has been
> discussed in a number of blog-posts [2], cryptography in Javascript on the
> Web is unsafe at best today, although technically the Web Crypto API is a
> WebIDL that could be bound to programming languages beyond Javascript. Even
> with excellent implementations such as the Stanford Javascript Crypto
> Library [3], browsers still have to download possibly untrusted Javascript
> cryptographic code in order to obtain basic cryptographic functionality not
> provided natively by Javascript.

To be fair, I don't think this is where the contention is with regards
to JS security.

>
> Yet is Javascript cryptography doomed on the Web? Much of the critique of
> Javascript cryptography boils down to a critique of current Web browsers,
> and as has been shown by the W3C and browser vendors - the Web Platform can
> evolve. Due to TLS, almost every web browser and operating system already
> contains well-verified and reviewed cryptographic algorithms. At its core,
> the Web Cryptography API will simply expose this functionality to WebApp
> developers, with a focus on essential features such as cryptographically
> strong random number generation, constant-time cryptographic primitives, and
> a secure keystore. Without these functions, Javascript web cryptography
> would be impossible.
>
> Yet we realize the Web Cryptography API is only a single component in
> building the emerging Web Security model of which the Web Cryptography API
> is only a single component.

"is only a single component" appears twice here.

> For example,  one open issue is whether or not
> applications using the Web Cryptography API also should be required to use
> CSP to prevent XSS attacks [4]. Indeed, should and can browser vendors and
> the W3C as a whole tackle the malleability of the browser Javascript
> run-time environment? Without a doubt these security considerations of
> utmost importance, and getting them right to enable cryptography on the Web
> will require holistic thinking about attack surfaces and threat models.
> There are a number of use-cases, such as checking digital signatures to
> out-of-band key provisioning, that our API hopes to enables by allowing
> key-based encryption and trust to be used in Web applications.
>
> One issue with the Web Cryptography API is that the Working Group decided to
> expose the low-level functionality first rather than aiming only for a
> high-level API aimed at the developer on the street who may not have a grasp
> of the finer details of cryptography. The Working Group did this on purpose
> after taking a survey of users [5], in order to allow experienced developers
> to build the functionality needed across the largest number of use-cases,
> but a "high-level" API that makes using cryptography easy for Web developers
> is still on our agenda. However, the Working Group decided to iron out the
> low-level details, in particular as regards keys and key storage, before
> moving to thinking about a higher-level and more simple API.
>
> A second issue is that the current Web Cryptography API exposes legacy
> cryptographic algorithms with known weaknesses such as those in  RSA PKCS#1
> v1.5, which was done in the draft to allow Web Application developers to
> create applications with interoperability with widely used applications such
> as GPG, SSH, and the like. These algorithms are not required to implement,
> but if implemented, we felt they should be uniformly specified across
> browsers. In our next iteration of the Web Cryptography API, we will label
> any algorithms with known weaknesses at our time of publication with
> sufficient warnings that the algorithm is not suitable to encrypt data and
> provide preferable alternatives.

Did we have consensus for this? We had discussed, and it seemed like
opinions were mixed on this - how much should be labeled in the draft
and how much should be labeled elsewhere?

With every one of our algorithms, it's possible to use it
"insecurely", and the issues with PKCS#1 v1.5 are predominantly with
implementation issues, as opposed to fundamental algorithm issues
(although I realize that some will argue that *because* there can be
implementation issues, it's a fundamental algorithm issue)

I'm hesitant to call this a firm commitment, if only because it's
unclear what we're committing to at this point.

>
> Is releasing this cryptography in Javascript to developers responsible?  Of
> course, cryptography can be used for both great good and great harm. Yet
> given the current dangerously insecure state of Javascript cryptography and
> the fact that developers are already re-implementing cryptographic functions
> in Javascript, myself and others at the W3C thought that action should be
> taken. Yet who we're really interested is not what we think, but what you
> think.

Is that what motivated the WG? This certainly didn't match my
understanding of at least what the WG was trying to accomplish in
chartering. What I qualify with is that this seems to make it out that
our goal is to solve "dangerously insecure state of Javascript
cryptography" - which sets a certain set of priorities to our work -
as opposed to perhaps other goals, such as enabling richer web
applications with secure key storage.

One could argue that, functionally, they're the same goal, but I fear
that how it's presented may set expectations for the set of problems
we SHOULD be solving.

>
> The entire point of releasing a Working Draft is to get the wider input of
> the community before we set the API in stone by implementing it. Indeed, we
> purposefully released the API at an early stage, when many of the basic
> issues are still unresolved, in order to get community input. Indeed, most
> of the work of the Working Group has been on identifying the space of
> unresolved issues, ranging from how to determine where a key is stored and
> key naming. Many of these open issues are given in the fourteen open issues
> in the specification itself, with more in the issue-tracker [6]. What we
> really want is detailed comments about the space of design issues, in
> particular those currently listed as open issues. Also additional use-cases
> and development of current use-cases would be appreciated, which are
> currently being stored on our wiki [7].
>
>  So please take the time to carefully review the First Public Working Draft
> and send comments to the public-webcrypto@w3.org mailing list, where we will
> respond to you!
>
> [1]http://www.w3.org/TR/2012/WD-WebCryptoAPI-20120913/
> [2]http://www.matasano.com/articles/javascript-cryptography/
> [3]http://crypto.stanford.edu/sjcl/
> [4]http://www.w3.org/TR/CSP/
> [5]http://www.w3.org/2012/webcrypto/wiki/SurveyAnalysis
> [6]http://www.w3.org/2012/webcrypto/track
> [7]http://www.w3.org/2012/webcrypto/wiki/Use_Cases
>
>

I think overall, this is a great start, and thanks for taking the time
to draft this and get the word out. I apologize that I haven't offered
more concrete wording alternatives, and I think by and large, the
issues raised with the proposed text are minor. I just wanted to
highlight them in case you perhaps had an alternative way of wording.

Cheers,
Ryan

Received on Monday, 8 October 2012 17:37:43 UTC