Re: Origin-bound keys

On Aug 6, 2012, at 10:02 AM, Ryan Sleevi wrote:

> On Mon, Aug 6, 2012 at 9:38 AM, Mark Watson <watsonm@netflix.com> wrote:
>> All,
>> 
>> Based on the discussions at our face-to-face I'd like to propose that we
>> make a distinction between keys which can be used by any origin (subject to
>> per-origin user authorization) and keys which can only ever be used by a
>> single origin (the one they were created by or provisioned for).
>> 
>> The first kind I call origin-authorized, the second origin-specific.
>> 
>> The reason I think this distinction is useful is that the privacy properties
>> of these two kinds of key are very different. Creating a key which can only
>> ever be used by the app that created it is a very different thing than
>> creating a key which may be used by other apps as well, depending on which
>> dialogs the user blindly clicks through.
>> 
>> Decisions on authorization dialogs etc. are taken by browser implementors
>> (not us in the web crypto group), but they may make different decisions for
>> these two cases if they are distinguished - to the benefit of users.
>> 
>> For example, origin-specific keys are much like cookies today and may be
>> controlled in a similar manner.
>> 
>> Origin-authorized keys are perhaps more of an uber-cookie where more care is
>> required. Perhaps a user authorization step is required to create one ?
>> User-authorization is definitely required to access one.
>> 
>> If we don't make this distinction in our API (in the form of a key
>> property), there is no opportunity for browsers to treat the two kinds
>> differently from a privacy/user authorization perspective.
>> 
>> …Mark
> 
> Mark,
> 
> I think this is a good continuation of the classification schemes
> proposed both by myself and Vijay, as it relates to temporary vs
> persistent vs high-value and related.
> 
> While I can understand the desire for a site operator to simplify the
> security properties by ensuring keys are origin-specific, I'm deeply
> concerned about the user experience under such a scenario.
> 
> An argument for origin-specific keys might be that it restricts the
> scope of operations to a single/small subset of origins. The assumed
> benefit would be that if any messages are generated using that key, it
> must have come from this set of origins.

I mean that any script that wants to perform an operation with that key must have come from that origin. Obviously, this is more useful with https origins.

> Additionally, it can
> presumably minimize the use of user-interaction when the user agent
> has someone sitting at a terminal.

Exactly.

> 
> An argument against origin-specific keys is that, by default, they
> promote application 'lock-in'. For example, if a user generates a key
> that will be used to assert some identity, if that key is flagged as
> 'origin-specific', the user will not be able to migrate their key to
> another application/provider of the identity service. Additionally, in
> the event the application needs to change origins (eg: rebranding,
> acquisition, domain sharding), either specific functionality for
> extending/altering origin-specific keys will be necessary or the
> application will simply break.

I'm suggesting we support both kinds. Whether you can 'migrate' an identity created for one application to another, unrelated, one is always going to be a decision of the application provider. 

I see the 'change origin' issue for pre-provisioned origin-specific keys - where the origin is also pre-provisioned. But otherwise I think you could accomplish it by creating a new key for the new origin and doing some kind of hand-off on the application side (hand-wave hand-wave…).

> 
> I'm not sure I'd agree that there are security properties imbued to
> origin-specific keys, as a number of things can "go wrong" that allow
> origin-specific keys to transition to origin-authorized keys:
> - Browser A and Browser B share the same logical keystore, which are
> used to store both origin-specific and origin-authorized keys. All
> "foreign" (eg: not generated within the particular browser) keys are
> treated as "origin-authorized". Metadata about origins is *not* stored
> in the key store, but stored in some browser metadata. If Browser A
> knows that Key A is origin-specific, but Browser B doesn't, then it
> might treat Key A as origin-authorized, and allow it's scope beyond
> the intended origins.

I think you need to store the authorized origins for a key with the key. So if browsers share a key-store they will see the same information.

> - Browser A may store keying material in the clear. A user may then
> export that keying material and import it directly into Browser B
> (which uses a separate key store), a transition which causes any
> associated origin meta-data to be lost.
> - Browser A is installed and generates Key A as an origin-specific key
> in some persistent key store. It is later uninstalled, but generated
> keys are specifically requested to be preserved. Later, Browser A is
> re-installed, but the meta-data about Key A being origin-specific is
> lost.

Ok, so these are ways a purportedly origin-specific key could become origin-authorized. If such a possibility exists the key is not really origin-specific in the first place because origin-specific requires that it can never be used by another origin.

The strength of the promise that a key is really origin-specific is like the strength of any other promise the browser makes about the security of the web crypto system.

If a browser supports origin-specific keys, it shouldn't allow those to be exported somewhere where the origin and the origin-specific nature of the keys will be lost. Of course sophisticated users could work around that by extracting the key from an unencrypted key store, just as a user could take a cookie and put it back into the cookie store with a different origin attached. Such a user is reasonably expected to understand the privacy implications of what they are doing.

> 
> Could you explain more the distinction between the two types,
> especially as it relates to their security properties? My first take
> from reading this is that the notion of "origin-specific" is directly
> related to "pre-provisioned", so I'm trying to separate out the two
> uses and needs.

Well, pre-provisioned origin-specific keys is what we would like for our use-case ;-)

But one can imagine the application specifying when a key is generated that it should be origin-specific or origin-authorized.

The difference is that in the origin-specific case the application is requesting that the browser never allow this key to be used by another origin. Another origin would just not see this key at all if it queried for it.

In the origin-authorized case, if another origin looks for this key that may trigger a user interaction to give that other origin access to it.

I can imagine that people could take a different view about the user-interaction - and other - requirements for origin-authorized keys. Creating a key that may later be visible to another origin might be something you want to warn the user that an application is trying to do. Otherwise, when they are later asked whether origin X can see key Y they may well wonder what key Y is.

On the other hand, letting applications transparently create origin-specific keys seems no more harmful than letting them create cookies.

…Mark

> 
> Regards,
> Ryan
>

Received on Monday, 6 August 2012 18:01:27 UTC