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

Hi.
to verify "certified/signed and 'installed' webapps",
we have to associate it with the certificate that is trusted in user agent.

regards
mountie.

On Tue, Oct 9, 2012 at 4:22 AM, David Dahl <ddahl@mozilla.com> wrote:

> I am curious if the W3 has ever couched the usage of a recommended API
> with caveats. (TBH I doubt it, but asking anyway) In this, I mean that we
> might be able to get more feedback focus on the API itself instead of the
> mostly short-circuited feedback on browser-as-a-whole security issues.
>
> I would like to explore (potentially) recommending usage of this API for
> DOM implementations where the "webapp" is cryptographically signed and
> "certified" by a trusted broker, e.g.: Mozilla Firefox OS and it's AppStore
> or similar environments. In this case, the Webapp is delivered as a
> zipfile, signed by the developer, installed on the device permanently via
> the FirefoxOS appstore. The App is verified upon install and updates are
> also signed.
>
> This is much more akin (and safer) to using an extension over a
> traditional web app.
>
> The other idea I am toying with is also recommending this API for browser
> vendors to implement as an extension API at first, rolling out to
> certified/signed and 'installed' webapps, with general browser content DOM
> usage as a completely experimental usage type for the time being.
>
> Thoughts?
>
> 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.catetc.)
> > 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
> >
> >
>
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World