- From: Mountie Lee <mountie.lee@mw2.or.kr>
- Date: Sun, 14 Oct 2012 01:11:40 +0900
- 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>
- Message-ID: <CAE-+aYLWd5sCNOwK0pZfkw8VtaBSR5JxD2YzVubEV2R4HDEU1g@mail.gmail.com>
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 UTC