Re: Origin-bound keys

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. Additionally, it can
presumably minimize the use of user-interaction when the user agent
has someone sitting at a terminal.

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

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.

Regards,
Ryan

Received on Monday, 6 August 2012 17:03:07 UTC