Re: crypto-ISSUE-21: Requiring Content-Security-Policy [Web Cryptography API]

I personally would want to use this API with the strictest CSP headers possible, but Vijay has a good point here. We should add a 'developer best practices' section to the spec or wiki to outline the additional security measure to take when using the API.

Cheers,

David

----- Original Message -----
From: "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com>
To: "Ryan Sleevi" <sleevi@google.com>, "Wan-Teh Chang" <wtc@google.com>
Cc: "David Dahl" <ddahl@mozilla.com>, "Web Cryptography Working Group" <public-webcrypto@w3.org>
Sent: Monday, August 27, 2012 4:59:06 AM
Subject: RE: crypto-ISSUE-21: Requiring Content-Security-Policy [Web   Cryptography API]

I'm not convinced of the value of requiring CSP in the first place. This is not a statement for or against CSP by itself; I just don't know what tying WebCrypto to it buys us.

It is not the mission of this WG to single-handedly make all browser JS safe. An app with a security hole is broken with or without WebCrypto, and CSP itself is a defense-in-depth measure. We also have use cases (non-browser JS has been brought up) where CSP may not be necessary at all. Finally, I'm leery of going down the slippery slope of specifying policy and not just mechanisms in the API.

Why not just recommend use of CSP in Security Considerations and leave it at that?

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Thursday, August 23, 2012 5:44 PM
To: Wan-Teh Chang
Cc: David Dahl; Web Cryptography Working Group
Subject: Re: crypto-ISSUE-21: Requiring Content-Security-Policy [Web Cryptography API]

On Thu, Aug 23, 2012 at 5:38 PM, Wan-Teh Chang <wtc@google.com> wrote:
> window.crypto.getRandomValues is the other operation that does not 
> require a key. In addition to the digest operation, getRandomValues 
> should also be considered when we resolve this issue.
>
> Wan-Teh

Good point. Perhaps it's worth doing the interface split then.

It was pointed out to me by a colleague that a CSP such as 'self' may be too prohibitive, in that it actively restricts the inclusion of script or objects from other domains, and suggested simply the following
1) Require SSL
2) Require that 'unsafe-eval' NOT be present
3) Require that 'unsafe-inline' NOT be present

That's also reasonable approach, but it does increase the attack surface of the API.

A possible refinement of the above proposal would be to allow, during key generation, whether the key was to be extended beyond 'self'. That is, restated:
#4) If a key was generated in 'self' mode (for lack of a better word), it would only be available on window.crypto.keys when the CSP also indicated 'self'.

The default mode for keys would be 'permissive' (eg: only require items #1 - #3), but optionally during generation/provisioning/import,
#4 could be specified.

Received on Monday, 27 August 2012 18:49:57 UTC