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

I was just thinking that another possible compromise might be that we specify that implementations at the very least SHOULD trigger a browser console warning when the API is used without CSP enabled.

Cheers,

David  

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

I think this is different from the tainting discussion.

The objection to tainting was related to it being specified in the implementation SC section. The problem there is that an implementation is faced with a choice - they can either implement tainting and break certain common operations, or forgo tainting and be seen as insecure. Tainting is a fine thing to include in the developer SC section, because the application developer can and should do a good job with it.

With CSP, I'm just trying to figure out what security objective is being sought, and how it is related to the charter of this WG. It seems to me that by requiring a specific CSP profile we're seeking to ensure that an application using WebCrypto is also free of various unrelated vulnerabilities (e.g. script injection). While this is a fine objective, it seems like an expansion of our scope.

I am also struggling to understand how the origin restrictions already defined in this API (especially with respect to keys) interact with the different CSPs that may be specified by an application. I wonder if we are not better off at least deferring the discussion until we have a better handle on those issues. In general, I agree with the idea that our origin restrictions should follow the same constructs as CSP.

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

On Mon, Aug 27, 2012 at 2:59 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com> wrote:
> 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.

Trying not to repeat the mistakes of the past two decades, when defining a new API, I think we should make use of the knowledge, experience, and risks learned in the past.

That is to say, sure, it's not essential to tie it to CSP, but then you'll leave it in the realm of implementations to do so (which I think we're likely to do for general usage, but practically assured for any non-browser-maintained key storage)

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

Sure. But if a new JS API has a host of new security considerations - and certainly, this does, with the frequent talk about pre-provisioned or out-of-band keys - then I think it's reasonable to have that API require stronger security guarantees than the existing ('broken') guarantees today.

As it relates to non-browser-JS, our charter is within the W3C, and we're scoped to Browser objects. To the extent non-browser-JS can use the same bindings is fine, but I think it's inevitable that they will have to adjust the spec to their non-browser needs. This is no different than how existing non-browser JS bindings handle existing W3C specs, so I don't think it's a statement one way or the other.

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

Previously, the addition of key taining to the Security Considerations was objected to, because it leaves some behaviours implementation dependent if it's not mandated. As such, it was moved to the Editor's Note for the time being. Moving CSP to the SC seems to be a prelude to the same discussion, with the end result is that no reference to CSP appears in the final document or it is required.

Currently, no normative text requiring CSP appears - but I think adding it is the right step.

>
> -----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 Tuesday, 4 September 2012 19:22:31 UTC