RE: PROPOSAL: Close ISSUE-19 - Does it make sense to have authorized-origin and specific-origin keys

Richard, and all,

The fact that there are some comments on that issue demonstrate that we should not close it, but rather consider it as a potential feature to be added. 

Can we have a text proposal from you to be included in the spec ? 
This would help to clarify the exact feature and scope, and feed editors to evaluate how complex or easy it is. 

Thanks,
Virginie

-----Original Message-----
From: Richard Barnes [mailto:rbarnes@bbn.com] 
Sent: mardi 5 février 2013 15:33
To: Ryan Sleevi
Cc: public-webcrypto@w3.org
Subject: Re: PROPOSAL: Close ISSUE-19 - Does it make sense to have authorized-origin and specific-origin keys

Inline.


>>> Granting access to the same key to multiple origins allows any of 
>>> those origins to spoof messages between eachother. To some, that's a 
>>> feature. To most, that's a security risk.
>> 
>> I'm not sure what you mean by "spoof messages between each other".  If you assume that a key is bound to a domain in the first place -- in the sense of some remote entity's understanding, not in terms of the API -- then sure, cross-origin sharing allows the recipient origin to masquerade as the sending origin.  But it's not clear to me that the assumption in the previous sentence is valid.
> 
> No, I'm talking about having good.example and evil.example. If 
> evil.example can access good.example's key (whether it be through XSS 
> and modifying the origin attribute, wrapping, etc), then evil.example 
> can spoof messages as if they arrived from a user agent authorized for 
> good.example.

Your example assumes that evil.example can cause good.example to send it the key.  If that's the case, then evil.example could just as well have good.example do its evil deeds without exporting the key.  Doesn't seem like there's any incremental increase in risk.


>>> There's further the question about how that reasonably interacts 
>>> with user security expectations.
>>> 
>>> It further creates an opportunity to allow origins to bypass 
>>> existing origin communication mechanisms, by using keys to 
>>> coordinate as persistent tracking identifiers across multiple origins.
>> 
>> I don't see anything new here.  Domains can already pass the value of a cookie, or some token to be held in localStorage.
>> 
>> In fact, you can do better here than those examples, because the UA can impose controls on which origins can actually use the key.  Those controls can be done outside the scope of this spec, much like the privacy controls on the Geolocation API.
> 
> So you're proposing user interaction? Note the significant opposition 
> that was raised with mandating user interaction. I also anticipate 
> that other user agents (besides ourselves, naturally) will have 
> concern in that any proposal that ultimately forces these sorts of 
> nuanced security decisions (even more than geolocation) to be a 
> problematic practice in general, to be ideally avoided. We discussed 
> during the Lyon F2F on possible schemes to balance the privacy 
> concerns with the desire for a non-interactive workflow.

I'm not mandating UI.  I was just saying that if you wanted additional controls or UI, you could add them without impacting the spec -- including restricting keys to use with one origin without any UI.  


>> Maybe you're envisioning a different flavor of key than I am?  In my mind, a Key object is a static collection of bits, which represents the key in a way that is intelligible to the API, but not to the application (except for the exposed fields).  In that case, you don't even get a covert channel from, say, changing key attributes.
>> 
>> --Richard
> 
> The key data itself is nothing but a random, unique value. That 
> carries with it privacy concerns.

No more so than the numerous random unique values that are already available.  


> Further, introducing attributes (as
> you seem to be supporting elsewhere) directly induces covert channels
> - or requires even more complicated access-control / permissioning 
> schemes than would be usable.

To be clear, I'm talking about passing by value, not by reference.  In that case, attributes would form no more of a covert channel than fields in an JSON object I put through postMessage -- a change in the recipient origin would not propagate back to the sending origin (and vice versa).  

(And to be clear, I don't really care that much one way or the other about attributes.  I just think that if we're going to do them, we should do them right.)


> Is there a use case and is there a proposal to put forward? Otherwise, 
> as expressed on the F2F call, I would rather close/move issues that 
> are "nice to have" from the list of "must have before advancing"

I thought that Mountie and others had requested this service.  The use cases for passing at least public keys seem obvious.  

And in any case, what I'm proposing is not a huge spec change.  It would place a constraint on Key objects (they must be self-describing), and probably add some comments on the risks of cross-domain sharing for apps using the API.

--Richard




>> 
>> 
>> 
>> 
>> 
>>> On Mon, Feb 4, 2013 at 12:00 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>>>> IIRC, you had invited proposals for cross-origin key management in a previous call.
>>>> 
>>>> PolyCrypt has one example of how to do so.  In that context, Key objects are self-contained; the key object contains a wrapped version of the actual key data, encrypted under a symmetric key held by the API implementation.  When an operation using the key is to be performed, the API unwraps the key and performs the operation.
>>>> 
>>>> The upshot of this design is that keys can be cleanly transferred between domains using mechanisms like postMessage, so that cross-domain sharing of keys is solved trivially using existing mechanisms.  An implementation could layer cross-origin restrictions on top of is by including information out the "owner" domain within the wrapped (and thus integrity-protected) key octets.
>>>> 
>>>> I'm not sure how this would show up in the API spec, however.  Maybe there's some interface (Transferable? Clonable?) that would encode these expectations.   We could discuss this implementation possibility as a possible realization.
>>>> 
>>>> --Richard
>>>> 
>>>> 
>>>> On Jan 31, 2013, at 2:11 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>>> 
>>>>> http://www.w3.org/2012/webcrypto/track/issues/19
>>>>> 
>>>>> I would like to propose that we CLOSE ISSUE-19. The group has not 
>>>>> made any progress on this issue since it was raised in August 
>>>>> 2012, nor have there been any proposals on how to resolve this.
>>>>> 
>>>>> The current specification limits storage to single-origin, 
>>>>> consistent with all other web storage APIs. There have been no 
>>>>> proposal for origin-authorized keys at this point, and such 
>>>>> proposals would introduce significant security concerns that would 
>>>>> need to be resolved.
>>>>> 
>>>>> I would like to propose that this issue be CLOSED against the 
>>>>> current specification.
>>>>> 
>>>> 
>>> 
>>

Received on Thursday, 7 February 2013 14:25:41 UTC