Re: Origin-bound keys

Hi.
I think this use case has similar purpose of Signed JS and JS integrity
checking (by my previous mails)

the service provider want to make sure the JS or the part of information in
client side is protected or not altered from the origin.

I think it is considerable.

regards
mountie.

On Tue, Aug 7, 2012 at 4:41 AM, Mark Watson <watsonm@netflix.com> wrote:

>
> On Aug 6, 2012, at 11:34 AM, Ryan Sleevi wrote:
>
> > On Mon, Aug 6, 2012 at 11:00 AM, Mark Watson <watsonm@netflix.com>
> wrote:
> >>
> >> 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.
> >
> > While hand-waving about UI decisions (as I tend to get UI horribly
> > wrong as a general rule), it seems to me that generating
> > origin-specific-and-persistent keys is equally troubling, because it
> > encourages application providers to 'lock-in' keys to their specific
> > origin.
>
> I don't really understand this concern. A key created by one origin can
> only be used by another with the cooperation of the first. In the case of
> symmetric keys they need to share the actual keys. In the case of key pairs
> with certificates establishing some form of identity they need to share the
> public key of the key pair used to sign the certificate. You can't share
> the keys across origins without the application providers consent anyway
> and if they give their consent then they'll use origin-authorized keys.
>
> >
> > My thoughts on origin-authorized user interaction is that /any/
> > application can create an origin-authorized key without special UI.
>
> I'm worried that not every implementation will agree with that (and may
> require user interaction).
>
> > It's only when another origin attempts to discover keys with a 'broad'
> > query (eg: rather than specific IDs, it says 'all RSA keys'), and no
> > pre-existing per-origin grants exist, that the user may be prompted to
> > select from an existing set of origin-authorized keys.
>
> In our use case, we will create several "session" keys through key
> agreement, authenticated with the pre-provisioned key. The session keys
> then have a lifetime of some number of hours or days. These keys would be
> meaningless to any other application and also to users. I would not want
> users to get dialogs showing big lists of incomprehensible UUID-identified
> keys that were intended to internal use by individual applications.
>
> This is perhaps another way of making the distinction. Not all keys are
> meaningful to other origins. Especially symmetric keys.
>
> > This is, in
> > effect, the SSL/TLS client certificate security model, but applied to
> > keys rather than certificates. This seems to mesh particularly well
> > with the Secondary API features, which is why I'm so fond of it.
> >
> > Though it's probably an unrealistic security posture, my gut is that
> > the decision about whether keys are origin-specific or
> > origin-authorized is a decision better left up to the user (or
> > further, not even specified), since it affects both their privacy,
> > potentially browser flexibility (since it now requires a formal
> > specification of the stable key storage), and their flexibility to
> > choose between web application providers. The question is: Are there
> > situations where the application may wish origin-specific, but the
> > user wishes origin-authorized? I think so.
>
> Can you give an example ?
>
> I think it reduces flexibility if the information about the intended use
> of the key (only ever with one origin, or possibly with other origins) is
> not available to the browser. We miss opportunities for improved user
> experience because all keys have to be treated like they will be used
> elsewhere when most of the time that will not be the case.
>
> >
> > Where I'm having trouble with is understanding if there are particular
> > _security benefits_ from making the distinction, or if the concern is
> > primarily related to UI? If the latter, then couldn't origin-specific
> > pre-provisioned keys be handled by implementations that support such
> > keys? eg: in the Netflix case, couldn't the Netflix User Agent simply
> > know that certain keys are origin-specific, and only expose them for
> > particular origins, and to do so without prompting? This avoids having
> > to spec the distinction, and leaves implementations the flexibility to
> > implement according to their underlying key storage mechanisms.
> >
>
> For the pre-provisioned keys, yes: we can just say that these must only be
> exposed to the netflix.com origin.
>
> But we'd like the generated session keys to have the same property and for
> user to suffer no more from their existence (in terms of privacy, control
> and confusing UIs) than they do today from site-specific cookies).
>
> …Mark
>
>
>
>
>

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World