RE: Origin-bound keys

Ah, I see. Thanks for clarifying. I was thinking of this as app-created origin-bound keys derived from a pre-provisioned origin-authorized key, hence the confusion.

-----Original Message-----
From: Mark Watson [mailto:watsonm@netflix.com] 
Sent: Tuesday, August 14, 2012 9:51 AM
To: Vijay Bharadwaj
Cc: Ryan Sleevi; public-webcrypto@w3.org
Subject: Re: Origin-bound keys


On Aug 14, 2012, at 9:37 AM, Vijay Bharadwaj wrote:

> I think I see where Mark is coming from.
> 
> To borrow a colleague's metaphor, I think this is an argument between the jail and castle models of isolation. The jail model is where one designs isolation containers (e.g. origins) primarily with the intention of preventing escape from the container; preventing outsiders from doing harm to inmates is a secondary or non-goal. The castle model of isolation is where the primary goal is to protect those inside the container from the depredations of outsiders. Least-privilege solutions are in a sense voluntary jails.
> 
> I think Mark is saying that he wants to be in jail and Ryan is arguing 
> that Mark should not be allowed to live in a castle :)
> 
> It seems to me there are benefits to the model Mark is asking for; the idea that an origin should be able to designate a resource it created as limited to some scope is appealing. If all apps did this, it would reduce the probability of a buggy application interfering with other applications. This does not preclude the possibility of cross-origin use of keys, it just means it has to be done out of band.
> 
> I can't convince myself about the need for pre-provisioned origin-specific keys though. I think that potentially leads to cookie-licking (either by incompetence or malice) where the first application to appropriate a pre-provisioned key can deny all other apps access to it.

That's not the intention. What I mean by a pre-provisioned origin-specific key is that there is a pre-provisioned key specifically for netflix.com. Only netflix.com can get it. And there may be another one for hulu.com etc. This is common in CE devices today.

There is a simple way to provide such keys which does not mean that you have to physically embed a separate key for each possible origin: Embed a single master key and use this to mint a new key in a deterministic manner for each origin that wants one. For example by hashing the concatenation of the single master key with the origin name. Out of band, the manufacturer can inform any origin that asks of the pre-provisioned key that will be visible to that origin's scripts, without revealing the master key to anyone.

Some systems support remote in-field provisioning of such keys by the device manufacturer, again meaning they can be minted 'on demand'.

> In my mental model all pre-provisioned keys are origin-authorized by definition since the user agent lacks the ability to arbitrate competing claims from different origins on the key. If a key needs to be origin-specific, then it must be provisioned by the application.

See above.

> 
> -----Original Message-----
> From: Mark Watson [mailto:watsonm@netflix.com]
> Sent: Monday, August 13, 2012 5:45 PM
> To: Ryan Sleevi
> Cc: public-webcrypto@w3.org
> Subject: Re: Origin-bound keys
> 
> 
> On Aug 13, 2012, at 4:38 PM, Ryan Sleevi wrote:
> 
>> On Mon, Aug 13, 2012 at 3:55 PM, Mark Watson <watsonm@netflix.com> wrote:
>>> Ryan,
>>> 
>>> To follow up on the discussion on the call today, I'd like to check if I understood correctly what you said about the id field being origin-specific correctly:
>>> 
>>> Suppose https://netflix.com uses Diffie-Hellman key generation to generate a key (A) which it gives the id 'netflix-key'.
>>> 
>>> Suppose https://freenetflix.com also uses Diffie-Hellman key generation to generate a key (B) which it also gives the same id, 'netflix-key'.
>> 
>> I think it's still an open issue where .id will contain the 
>> 'meaningful' id (eg: application gets to define its identifiers), 
>> like you've described here, or whether it contains a 
>> browser-auto-generated name.
>> 
>> I strongly believe something like blobURIs or equivalent is 
>> appropriate here - eg, http://www.w3.org/TR/FileAPI/#url
> 
> I don't much mind whether the identifier is app or UA-generated. It doesn't really affect this discussion.
> 
>> 
>> So, as proposed in the past by (I believe) ddahl, the id here would 
>> contain a canonical UUID.
>> 
>> Under such a scheme, you would have keys with attributes/value pairs, 
>> such as via KeyAttributes. Something like { 'name': 'nflx-ksh' }
> 
> I thought you were against the kvps ? Anyway, if the UA generated the identifier, I can just put my mapping in local storage/IndexDB "nflx-ksh" : "54efigf88iuyte4oqt==".
> 
>> 
>>> 
>>> Keys (A) and (B) are necessarily different having come from separate DH exchanges. Later, if https://netflix.com attempts to use the key with id 'nflx-ksh', which key will be used ? A or B ?
>>> 
>>> I understand from the ids being origin-specific, that A and B are separately stored and that https://netflix.com will get key A, right ?
>> 
>> Yes.
>> 
>>> 
>>> Next, if only https://netflix.com has generated a key as above and then http://freenetflix.com attempts to retrieve a key with id 'netflix-key', what could happen:
>>> (a) this fails because http://freenetflix.com has never generated a 
>>> key with this id
>>> (b) the user is asked whether http://freenetflix.com can access key 
>>> id 'netflix-ksh' from https://netflix.com
>>> (c) the user is given a dialog saying 'please choose a key for 
>>> http://freenetflix.com to use as netflix-key from the following 
>>> list, where the list includes the https://netflix.com netflix-key 
>>> (and probably many others)
>>> 
>>> Or multiple of the above options ?
>>> 
>>> I would expect the answer in the first case is A and in the second case is (a). If not, I don't really understand what 'origin-specific' means in the definition of the id.
>> 
>> Dependent on the KeyQueryList parameters, I would think.
>> 
>> The default I think would be (a), provided the KQL was for some 
>> specific UUID. I would think (c) would come into play if the 
>> application indicated it would accept any key from any origin that, 
>> say, met the criteria { 'name': 'nflx-ksh' }.
> 
> So then I think that would discourage me from specifying the kvp - so 
> that it became more difficult for others to find my key ;-)
> 
>> Then it's up to the
>> implementation to decide appropriate behaviour (including prompt or 
>> app policy, as two examples), but with the default being "No, you 
>> can't".
>> 
>>> 
>>> Are you are looking for a method for an application to "generate a new key in a manner specified by the user", where the user could specify that the key be generated randomly, or that an existing key (from any origin) be used ? What other methods would you see providing a key generated by one origin to another origin ?
>> 
>> This is important when we consider this API as a replacement for 
>> <keygen>. Some implementations of <keygen> allow the user to select 
>> an existing key (or further alter the key generation criteria), 
>> others simply generate a new key every time.
>> 
>> When you consider the CA issuance model, such as what Mountie brought 
>> up and as discussed during the F2F, I think this is an important use 
>> case that we should be considering.
>> 
>> That said, I think I definitely agree with the application's 
>> abilities to provide hints and guidance for an implementation about
>> (origin-authorized) vs (origin-generated), but I don't think the spec 
>> should be have normative text about how to specifically handle those.
> 
> I think this would be another element in KeyGenerationParams, "same-origin" or something like that, with the definition "true if the application requires that the key should not be visible to other origins". 
> 
> I'm sure the wording will need some work. A restriction on allowing cross-origin access that is as strong as the similar restriction for local storage or cookies would probably be sufficient (presumably the user is allowed to override those restrictions, based on the same arguments you've given for keys).
> 
> ...Mark
> 
>> 
>> What do you think?
>> 
>> Ryan
>> 
> 
> 
> 
>

Received on Tuesday, 14 August 2012 18:34:33 UTC