W3C home > Mailing lists > Public > public-webcrypto@w3.org > October 2012

Re: Usefulness of WebCrypto API - proposal to move forward

From: Mountie Lee <mountie.lee@mw2.or.kr>
Date: Sun, 14 Oct 2012 01:11:40 +0900
Message-ID: <CAE-+aYLWd5sCNOwK0pZfkw8VtaBSR5JxD2YzVubEV2R4HDEU1g@mail.gmail.com>
To: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
Cc: Ryan Sleevi <sleevi@google.com>, David Dahl <ddahl@mozilla.com>, Seetharama Rao Durbha <S.Durbha@cablelabs.com>, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Nadim Kobeissi <nadim@nadim.cc>, David Rogers <david.rogers@copperhorses.com>, Harry Halpin <hhalpin@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
I have added my comments.

On Sat, Oct 13, 2012 at 9:50 PM, GALINDO Virginie <
Virginie.GALINDO@gemalto.com> wrote:

> 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-----
> >
>



-- 
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
Received on Saturday, 13 October 2012 16:12:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 13 October 2012 16:12:29 GMT