Re: Origin-bound keys

On Mon, Aug 6, 2012 at 12:41 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Aug 6, 2012, at 11:34 AM, Ryan Sleevi wrote:
>
>> 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.

I think this point may be where some of our misunderstanding comes
from. I believe that "A key created by one origin can only be used by
another with the cooperation of the first **or the permission of the
user**". Note the ** portion.

My view is that while access to keys is limited on an origin-based
security model, I do not think that the origin is the sole arbiter of
key security or access. This is consistent with the 'native code'
model, in which Application 1 stores a key in the user's OS layer key
store, and *any application* that runs on the user's machine can later
access that key. In our model of a JS API, "any origin" can
*potentially* access the key, dependent on the implementation and how
it exposes the key.

I feel like I've given sufficient examples about why I take this view,
particularly the "cloud storage" example, but if it would be helpful
for me to spell out why I think this is necessary, I'll be glad to do
so. I just want to make sure we're first understanding eachothers'
respective positions on the key security model.

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

And this is equally true for other APIs in the Web Platform space -
such as getUserMedia(), navigator.geolocation.getCurrentPosition(),
IndexedDB quota limits, etc. As Harry mentioned during the Face to
Face, the W3C tries to avoid requiring or forbidding certain UI
interactions, so I don't know if we can realistically accomplish the
desired behaviour in the spec. A conformant implementation could
prompt for *any* access for the Web Crypto API - for example, if it
was subject to timing attacks that could lead to key disclosure.

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

While I agree with the fundamentals, and while I'm certain Netflix's
use case is certainly intending to favor the user, I'm concerned about
sites that are less pro-user that use keys as a lock-in mechanism. I
believe the, at the end of the day, the user must remain in control of
the security and keying material on their system.

I think we'll continue to have the discussion about the 'right way' to
use the API, but I would expect that the only time dialogs or user
interaction even remotely come into consideration is when an
application gives a 'broad' KeyQueryList - that is, one which does not
try to specifically identify 'known' keys, and which it does not
indicate it's looking for keys it has already been granted access to.
Then, it's up to the implementation to decide how to react
accordingly; including a perfectly appropriate response which is to
say "no such keys exist" and never show any UI. That's up to the
implementation though.

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

Consider Applications 1 and 2, both of which wish to use
'origin-specific' RSA keypairs as part of the authentication workflow.
During the registration/enrollment phase, both applications have
workflows similar to the following:

1) Generate an RSA key pair of size X
2) Export the public key and send to the server
3) Associate the (username, public key) on the server side
4) For future authentication attempts, the user must perform some
signing operation with the private key

This is a rather simple, easy to understand auth flow.

One scenario would be that each origin generates an origin-specific
key pair (eg: they have no relationship to each other). That's fine,
and if that's all an implementation supported, the scenario fully
works as expected for both applications.

However, imagine the user already had an RSA public/private key pair
through some other means. It may even be stored in a
higher-than-normal security layer (stored in the OS with a
prompt-on-use semantic, stored on a secure element, stored on some
other device, etc). Rather than generating two origin-specific
keypairs, in addition to the one they already have, the user wishes to
*reuse* the existing key pair for both sites.

Yes, this allows Application 1 and 2 to collude and determine that
user-Application-1 is probably user-Application-2, since they both
share the public key, but that's done at the user's choice. (As it
stands, the applications can probably already collude based on either
username+password+ip matching, or by simply looking at the user's
email address, but that's a different story). In this case, even
though both origins requested origin-specific keys, the user provides
an origin-authorized key.

That may seem like a contrived example ("The user already had the key,
therefore it's different") - but I think it's also possible that this
high-security key was generated *by the user* when some OTHER
application (Application 3) was requesting a key - perhaps even an
origin-specific one!. At the time of generation, the user configured
all of these high-security options, which is how that key came into
being.

While I can certainly understand dialog fatigue, and again, I'm making
no commitment one way or the other with regards to UI, I'm trying to
leave this API sufficiently flexible that such implementation-specific
behaviours or features are not forbidden or impossible.

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

Users and user agents can already configure prompting for
site-specific cookies. Thus I think the point of 'like cookies'
highlights my concern - that implementations, not applications, should
be in charge of security relevant decisions.

Yes, for the 99.9% of users, they never encounter these prompts.
That's equally my goal with this API. But I do not think preventing an
implementation, or a user, from implementing prompting and/or key
migration, is something this spec should do.

Received on Thursday, 9 August 2012 18:04:57 UTC