Re: Usefulness of WebCrypto API - proposal to move forward

On Oct 15, 2012 9:05 AM, "David Dahl" <ddahl@mozilla.com> wrote:
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> +1 Your summation was more or less what I was getting at, of course, my
language about Firefox-specific tech was illustrative only (and not
intended for the actual spec).
>
> Cheers,
>
> David
>

Agreed - great summary Harry.

>
> On 10/15/2012 10:59 AM, Harry Halpin wrote:
> > How about this text - I've also added it to the etherpad. Apologies I
will not be at the meeting, but I tried to reflect both David and Ryan's
positions, as well as the feedback and work in the app. Some text has been
re-used from the blog post. I think it would be good to add something like
this (editors tweaking of course encouraged) just to make sure
> >
> > "Security Considerations:
> >
> > The Web Cryptography API presents a set of constant-time cryptographic
functions, key storage, and other features not natively provided by
Javascript. As such, the API itself only makes guarantees about the
correctness of its cryptographic functions and allows the provisioning of
key storage, and does not solve other security issues with either the the
JavaScript environment or the Web that are dealt with by other
specifications and solutions outside the scope of this Working Group, such
as the malleability of the Javascript environment within browsers.
> >
> > This API exists to deliver functionality to developers, and it is
assumed that the developers know how to implement secure protocols
correctly with the use of this API. There is always a risk of developers
using the functions provided by the API incorrectly, as there is with any
cryptographic library. In particular, this 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 GPG, SSH, and
the like. Developers interested in looking at solving larger security
issues with the Web should use TLS and also investigate, depending on their
particular environment, a number of other specifications and issues such as
but not limited to Content Security Policy, HSTS, Web Intents, certificate
pinning, System Web Applications with explicit permissions, and other forms
of restricted environments, as well as ensuring both their operating system
and servers are appropriately hardened. We expect the state of the art of
the Web Security Model to continue to evolve."
> >
> >>
> > Ryan:
> >
> > Indeed, the wording is too specific. I am hopeful that other browsers
beyond Mozilla products will take up Open Web Apps.
> >
> > 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
> >
> > 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_application )
> >
> > > 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/
>
> iQEcBAEBAgAGBQJQfDReAAoJEJfYh8Nd7p0f314H+QFPKKfty6fPildJ3EReKkc1
> Sb1ooKRjgwa0Km/1gwhMyT27HVXQ/PCa3bf150wd+kMNRQbA+kuDVyaMz3528Fv2
> bhZPi9hYJJoGz83h3IhAMEfZo3WzmJdASkkHG2IH7csT9RLQEC4LhMyT+flbW/Mf
> 3AO7t95EEgSHiAAspwW3etJr/2MQvdF5/aeBq4KvjHwo0VCxuE/49Xx7LS71TIZz
> cQcFtlzOwiVp1h3sDG43i6itvgotD6HHKEvzEoTkXFHUE6ayxGI5dJ2FCPNu3bIy
> /v0iQCWEuU3b55gl1FcPWa0f1EA1Tt2YhgBoPmf7aLFPTfQvay55rqESO6aVuXc=
> =sAT5
> -----END PGP SIGNATURE-----
>