RE: Usefulness of WebCrypto API - proposal to move forward

Dear all,

I suggest that we start amending David's proposal online to make it a WG position. 
I have created a collaborative pad here : http://lite.framapad.org/p/t7PEEmBztz , I have inserted the original text from David, but it should be amended to reflect Ryan suggestion to make it more industry neutral. 

Just indicate your name or usual nickname before typing, this will mark your revision with your name, save by clicking the star when you think you have finished... and lets see if we can reach a consensual position. 

Regards,
Virginie


-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: samedi 13 octobre 2012 01:26
To: David Dahl
Cc: GALINDO Virginie; Mountie Lee; Seetharama Rao Durbha; Vijay Bharadwaj; Harry Halpin; David Rogers; Nadim Kobeissi; public-webcrypto@w3.org
Subject: Re: Usefulness of WebCrypto API - proposal to move forward

On Fri, Oct 12, 2012 at 4:16 PM, David Dahl <ddahl@mozilla.com> wrote:
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ryan:
>
> Indeed, the wording is too specific. I am hopeful that other browsers 
> beyond Mozilla products will take up Open Web Apps.

Sure, and I think the SysApps WG is seemingly like the place for that.
While I have no fundamental issues to referencing browser-vendor specific solutions as examples, I do have issue with *recommending* them to be implemented. It seems like a back-door way to promote adoption, rather than a normative requirement (or even necessary a beneficial one on the informative layer)

>
> It sounds like the idea of recommending the API for 'restricted 
> browser environments only' is not working for you. Is there there any 
> kind of language along these lines you can imagine? Should we revisit 
> *strict* CSP + HTTPS as another avenue?
>
> Cheers,
>
> david

We can, but I think it further highlights the problem with your proposed wording. When previously discussing strict CSP and HTTPS, there was not consensus in the WG. So the proposed text does not seem to take into considerations the objections raised. Recall that because of this lack of consensus, it was requested that I remove the reference in previous drafts.

I do not think the proposed text reasonably addresses the concerns that were raised. Though it does focus on an important security consideration, and one that I am in agreement with you that it's valuable, I am neither convinced that it is a strict requirement nor am I convinced that it fundamentally addresses the concerns raised by public review, which seemed largely focused on concerns about 'stupid developers doing stupid things', rather than on the fundamental brokenness of JS security model. Yes, there was some concern about manipulation, but that does not seem to be the bulk of the concern.

>
>
> On 10/12/2012 05:48 PM, Ryan Sleevi wrote:
> > As previously mentioned, I object to the wording "This API is not 
> > recommended for use in content DOM web pages".
> >
> > While I have great respect for the Mozilla team, and definitely 
> > appreciate your wording changes, I am apprehensive about the 
> > proposed wording that specifically suggests that the only safe place 
> > to do this is within a Firefox-exclusive model.
> >
> > I've repeatedly provided examples of where the supposed benefits of 
> > the Firefox model can be accomplished within W3C work (again, namely 
> > CSP, and preferably HTTPS). Again, as I've repeatedly said, I think 
> > the insistence or recommendation that requires signed apps, or 
> > requires or recommends Firefox OS provides no security benefit 
> > (above and beyond the aforementioned W3C standards).
> >
> > On Fri, Oct 12, 2012 at 2:45 PM, David Dahl <ddahl@mozilla.com> wrote:
> >
> >>
> > On 10/12/2012 02:55 PM, GALINDO Virginie wrote:
> > >>> Dear all,
> > >>>
> > >>> >From the different exchanges held on this mailing list, I think
> > >>> that
> > we do have a structure for enriching our security considerations 
> > about the API. I think that we can write a WG position - as 
> > suggested by Vijay
> > - with all the details and rationale, make sure we all agree and 
> > consider putting this (or a summary) in the specification itself.
> > >>>
> > >>> I would suggest the following outline :
> > >>>
> > >>>
> > >>> 1- Considerations on 'local resources' (I mean UA and OS) 
> > >>> security
> > >>>
> > >>> 2- Considerations on server-webapp communication security
> > >>>
> > >>> 3- Considerations on the benefit brought by the API (e.g. 
> > >>> functional
> > and interoperability)
> > >>>
> > >>> 4- Recommendation to developers to establish a trusted 
> > >>> environment to
> > complete their security model (like : audit the platform (UA+OS), 
> > use CSP, use TLS, signature, ...)
> > >>>
> > >>> We discussed during our last call that David D would write 
> > >>> something
> > about security and environment : David would you like to expand this 
> > outline ?
> > >>> Anyone else to support this work ?
> > >>>
> >
> > Indeed, and the week has gotten away from me, however, this is what 
> > I wanted to propose we begin the section "Security Considerations" 
> > in the API draft:
> >
> > ---
> >
> > With the understanding that the web browser DOM is a perilous place 
> > fraught with multiple attack surfaces, the point of creating this 
> > API is not to solve these "generally insecure JS/DOMWindow context" problems.
> > The point is to design a crypto API that can theoretically be used 
> > to fulfill the use cases the Web Crypto API WG has drafted.
> >
> > While this API is not recommended for use in content DOM web pages, 
> > there are DOM environments that can more securely host this API.
> > ('Privileged' and 'Certified') Open WebApps ( see:
> > https://developer.mozilla.org/en-US/docs/Apps ), like those being 
> > created for Firefox and Firefox OS enable a restricted environment 
> > where the apps are cryptographically signed (and then verified upon 
> > install or
> > update) remote resources are quite limited, explicitly-granted 
> > permissions are required, eval() and additional JS and browser 
> > features are disabled, making the DOM a much more 'trusted' 
> > environment to operate in. ( see:
> > https://wiki.mozilla.org/Apps/Security#Installed_privileged_applicat
> > ion
> > )
> >
> > Web browser extensions are also a potential consumer of this API, as 
> > the extension APIs and SDKs of modern web browsers are arguably more 
> > secure contexts for code like this to run in.
> >
> > ---
> >
> > I have already discussed this concept somewhat with Ryan and others 
> > on the mailing list, with Ryan concluding that these environments 
> > are not any more secure than a web page with strict CSP and HTTPS 
> > enabled, I have re-read the Open WebApps security model (for 
> > 'privileged' and 'certified' apps) remembering that the eval attack 
> > surface is gone as well as a very strict CSP is in place. These 
> > restrictions along with a signed, installed zip-based application do 
> > seem to me to be a leap forward in securing and being able to trust the web app.
> >
> > Thoughts? Edits?
> >
> > Cheers,
> >
> > David
> >
> >
> >>
> >>
> >
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJQeKTYAAoJEJfYh8Nd7p0f8KUH/2Tyaizrj2jx0zofwm8JZyZt
> yUtq2q7PRvfBw61+/2P56nRA1E2TpU5mTeG5rzAj0pLUHcA/dzMjDtP4ZB8dZu39
> IvbvfZ9r8L/k+0R1+JM4jkIVeP73cKWacOmGDA6HgsfdSgJ8nGL1fwDA/S5n5cAX
> O0AkwyGvxt/3cJ7PYpH4JYQU2rLK+0wOGNyEYXi5snl9m9lRltUp5+FUqfNRxluE
> x4WnBo0PUWiMmenfgYphOQisuwlPPPgNsffe3hCy1Xp6CoGSpfewtYnRiI66sCjo
> xq1nZxMsvT2E19oOmxUfK5xLC0D2r3v3VddQhKTzHzOiJoMhY7e8Mu2/CbiHy6M=
> =3vZZ
> -----END PGP SIGNATURE-----
>

Received on Saturday, 13 October 2012 12:51:28 UTC