Re: Was: Draft Blog Post on Cryptography API, Now: Potential API recommendation caveats

----- Original Message -----
> From: "Ryan Sleevi" <sleevi@google.com>
> To: "David Dahl" <ddahl@mozilla.com>
> Cc: public-webcrypto@w3.org, "Harry Halpin" <hhalpin@w3.org>
> Sent: Monday, October 8, 2012 7:59:41 PM
> Subject: Re: Was: Draft Blog Post on Cryptography API, Now: Potential API  recommendation caveats
> 
...
> 
> As discussed on the call, I have trouble restricting this to an
> extensions only API - let alone because there is no common agreement
> on what extensions are. While the SysApps WG is nominally attempting
> to standardize this, our charter predates their work, and I don't
> think it'd be an appropriate time to suddenly say that we're not
> looking at allowing this for web content.

I actually do not want to restrict this API to extensions-only or "signed-and-verified-installed" webapps only. I think the "security considerations" language should emphasize that "SysApps" environments and extensions are the preferred environment for production applications and that any usage on the web in content DOM is not recommended until there is a "more trustable", standardized "SysApps DOM" in which to operate. Security gurus cannot seem to get past the malleable DOM part of the deployment problem and this is sadly limiting the feedback we desire from them.

Indeed, extension toolkits/ SDKs/ environments vary greatly between browsers, however, nothing stops browser vendors from implementing this  API for extension use.   

> 
> As demonstrated by our use cases, it's clear we have a desire to use
> this in extension-less contexts, and where the security properties
> are
> acceptable. This isn't true for all use cases, sure - but is for at
> least some of them. Requiring extensions would be a step back.
> 
> Previously I'd proposed TLS-only and only in the presence of CSP,
> both
> of which are arguably "sane" values. However, members objected to the
> requirement, in that it coupled this API with CSP. I'm not sure
> coupling with SysApps really addresses those concerns any better.

I think we should recommend this API for use with SysApps and extensions, not restricting its use on the Web - as this API will be quite valuable for research and development. I do think any use of this API in content DOM should raise WARNINGS, making it clear the use is experimental at best. 

> 
> As for VPN only, that's an incredibly difficult problem to actually
> recognize, and I don't think it's a solution we could really support
> (for example: is an SSL VPN a VPN or not?).
> 
> Note that I remain supportive (from an implementation side) of
> requiring things like SysApps in order to expose non-origin-bound
> keys
> (aka 'system crypto', which I remain concerned about the
> implementation of), but I'm not sure how much of that should be
> required by the spec and how much should be left up to
> implementations.
> 
Yes, this is an open question. I agree that origin-bound keys should be required for any content DOM use.

Cheers,

David

> >
> > ----- Original Message -----
> > From: "Ryan Sleevi" <sleevi@google.com>
> > To: "Harry Halpin" <hhalpin@w3.org>
> > Cc: public-webcrypto@w3.org
> > Sent: Monday, October 8, 2012 1:09:48 PM
> > Subject: Re: Draft Blog Post on Cryptography API
> >
> > On Mon, Oct 8, 2012 at 10:54 AM, Harry Halpin <hhalpin@w3.org>
> > wrote:
> >> On 10/08/2012 07:32 PM, Ryan Sleevi wrote:
> >>>
> >>> 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.
> >>
> >>
> >> That seems to be contention for lots of folks, as at best we
> >> reduce the
> >> security properties of JS crypto to TLS. Of course, this ignores
> >> the fact
> >> that digital signatures and many other things in Web apps are
> >> useful
> >> regardless. Hmmm...should I bring that out in the beginning?
> >>
> >> "obtain basic cryptographic functionality not provided natively by
> >> Javascript" -> " obtain basic cryptographic functionality not
> >> provided
> >> natively by Javascript such as digital signatures".
> >
> > Sorry, my point was that even with this API, there is still a
> > fundamental reliance on TLS to provide connection security (well,
> > outside of SysApps aka extensions). This API does not provide for a
> > replacement of TLS, since it's ultimately script delivered by a
> > remote
> > server.
> >
> > I think the primary "issue" with SJCL (and, again, it's a great
> > API,
> > not to be mistaken here), that this API can resolve, is not about
> > the
> > delivery of script (which is still an issue with this API), but
> > about
> > secure key storage - and to a lesser degree, constant-time, vetted
> > operations.
> >
> > Randomness was addressed by WHATWG, but we could highlight it here
> > again if it matters.
> >
> > I just think the current wording suggests that it's a "delivery"
> > issue, which I don't think it is.
> >
> >>
> >>>
> >>>> 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.
> >>
> >>
> >> Thanks for the catch! Again, trying to clarify we are not
> >> providing a magic
> >> bullet here, just a Crypto API.
> >>
> >>
> >>>
> >>>> 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?
> >>
> >>
> >> I was under the impression we agreed that the request from CRF and
> >> others to
> >> label them was reasonable and to label them in the draft. I'm not
> >> sure where
> >> "elsewhere" would be. But yes, we have not yet of course decided
> >> on the
> >> labelling scheme.
> >
> > The example of "elsewhere" was the IRTF document (
> > http://tools.ietf.org/html/draft-irtf-cfrg-cipher-catalog-00 )
> >
> > With all respect to Zooko, the concern is that the wording more or
> > less matches his proposal, which is an outstanding issue at this
> > time.
> >
> > An example of an alternative proposal was to list "Security
> > Considerations" on a per-algorithm basis, and to reference
> > appropriate
> > external sources for more details. Such a solution is very
> > different
> > than Zooko's, but functionally accomplishes the same goals, and is
> > what had been discussed prior to last week as being a workable
> > solution.
> >
> > So I don't think we've quite nailed down what "labeled" means yet.
> >
> >>
> >>>
> >>> 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.
> >>
> >>
> >> Yes, this is a hard point to phrase. However, I think the general
> >> point is
> >> that "Some of the algorithms can be used insecurely, but they are
> >> necessary
> >> for interoperability". Would that be a better way of phrasing it?
> >>
> >> So how about:
> >>
> >> "A second issue is that the current Web Cryptography API exposes
> >> legacy
> >> cryptographic algorithms that can be used and implemented
> >> insecurely, yet
> >> these are still needed in order to allow Web Application
> >> developers to
> >> create applications with interoperability with widely used
> >> applications such
> >> as..."
> >
> > Sounds reasonable.
> >
> >>
> >> "For our next iteration of the Web Cryptography API, we are
> >> considering
> >> labeling algorithms by their function, as well as possibly with
> >> known
> >> weaknesses at our time of publication and pointing to preferable
> >> alternatives for creating new secure protocols."
> >
> > Again, I think that gets us down the (reasonably) dangerous path of
> > trying to keep up to date with changes in cryptographic best
> > practice.
> > I would rather avoid "suggestive" text entirely - and highlight
> > known
> > issues at the time of publication.
> >
> > I think the real recommendation should be that web developers
> > should
> > not be developing new secure protocols. This is not crypto-elitism,
> > this is security pragmatism. If we're going to recommend anything,
> > I'd
> > rather recommend something like JOSE (which is to say, 'use the
> > high-level').
> >
> > But I don't know how committed we are to either normative or
> > informative recommendations.
> >
> >>
> >>
> >>
> >>>
> >>>> 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.
> >>
> >>
> >> I do not see the difference. Developers are already (see
> >> crypto.cat etc.)
> >> trying to make JS crypto apps, so an APi is necessary in order to
> >> enable
> >> secure key storage and other necessary components.  We could say
> >> instead
> >> "Given the fact that developers are already re-implementing
> >>  key-based
> >> cryptography in Javascript in order to create richer Web
> >> applications with
> >> key storage, my ..."
> >
> > I certainly can't speak to your goals, and leave you best to
> > qualify
> > them however you see fit. My concern was and is simply that "others
> > at
> > the W3C" may serve two interpretations. It may be seen to reflect
> > the
> > goals of members (eg: the WG participants), who I think have a
> > myriad
> > of different goals than trying to fix what /other/ developers are
> > doing. Or it may be seen to reflect what the administrative
> > arms/chairs/etc of the W3C see, which may be a different set of
> > member
> > organizations.
> >
> > Either way, there's a number of reasons why participants have been
> > participating, and I'm not sure the current text reflects the goals
> > of
> > all participants or fully qualifies that it's representing the
> > opinion
> > of individuals/the W3C as an organization.
> >
> > This is really a minor point, to be fair, but hopefully it's
> > clearer
> > now what my concern was.
> >
> >>
> >>
> >>>
> >>> 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.
> >>
> >>
> >> Thanks, and my suggested changes above. My goal here is to
> >> increase quality
> >> comments from the general public.
> >>
> >>>
> >>> Cheers,
> >>> Ryan
> >>
> >>
> >
> 
> 

Received on Tuesday, 9 October 2012 14:43:33 UTC