Re: Proposal for ISSUE-25 (Globally unique pre-shared keys)

On Oct 30, 2012, at 11:28 AM, Ryan Sleevi wrote:

> On Mon, Oct 29, 2012 at 9:07 AM, Mark Watson <watsonm@netflix.com> wrote:
>> 
>> On Oct 29, 2012, at 4:10 PM, Ryan Sleevi wrote:
>> 
> <snip>
>>> That is, the language "pre-shared keys"
>>> implicitly presumes (global? user-specific? multi-origin?) pre-shared
>>> keys, and then describes a function on how to get "unique
>>> origin-specific pre-shared keys".
>>> 
>>> It seems to me that your requirements for both user-access and
>>> derivation are thus *not* related to pre-shared/pre-provisioned keys,
>>> but more generally concerns regarding keys shared between origins.
>>> That's why I think it's a weird fit for where you put it.
>> 
>> Ok, well, I could move it, or even remove it (the transformation) because it was just an example.
> 
> SHOULD is more than just an example. It's a language that says "This
> is more or less a MUST, but we'll leave you a little bit of wiggle
> room".

The SHOULD is for making the keys origin-specific. The use of a master key which is transformed to origin-specific keys was an example of one way to implement that. I thought you were referring to the example because of your use of the word "derivation". 

> An example, particularly one where there seem to be a large
> number of use cases that run counter to it, would nominally be a MAY,
> or simply called out as just that - an example.

Yep, I say "for example … ".

> 
> If anything should be a SHOULD, it would seem like "ensuring the key
> is unique per origin", but while I understand that intent, I'm not
> sure it's well understood enough to include that as a SHOULD yet.

"ensuring the key is unique per origin" means something different from "ensuring the key is different across origins". But both should be a SHOULD and we can work on making those things better understood.

> 
> <snip>
>>> Right - so this really is a distinction between origin-specific and
>>> origin-shared keys, and not pre-shared vs generated keys.
>> 
>> IIUC, you're suggesting that any key shared across origins could be made origin-specific with a technique like this. That's fine. I wouldn't even call that an origin-shared key because there's no difference (as far as applications are concerned) between this case and keys which are totally independent.
>> 
>> There may be a difference as far as the user is concerned, as the user may know that both keys are ultimately generated from the same passphrase, for example.
> 
> That wasn't quite what I was suggesting, merely trying to make sure I
> was understanding what *you* were suggesting :)
> 
> It seem(s/ed) to me like your construct regarding the function
> transformation has *nothing* to do with pre-shared/pre-provisioned
> keys, and is entirely about ensuring origin-unique keys are the only
> keys used, which I'm not sure (yet) if it is workable.
> 
> To put differently, it seems your entire note about security is not
> re: pre-shared keys, and is entirely about origin-specific keys - a
> different (although possibly overlapping) class.

My intention was to apply the recommendation (that keys are origin-specific) only to pre-provisioned keys. 

I agree that the recommendation could be expanded to cover other cases, but I have no opinion on whether it should be so expanded.

Again, just to be clear, the recommendation is just that the keys be origin-specific (meaning different origins see different key values for a key that is the "same" in some other sense - likely from the user's perspective), not anything about how that is achieved.

> 
> <snip>
>>> I'm saying that the certificates associated with a key may not be
>>> stored with the key itself, nor is it a static list. For example, new
>>> certificates may be deployed via application/x-x509-user-cert (for
>>> user agents supporting it) at any point. What is the value of the
>>> attribute as keys are added? As they're removed?
>>> 
>>> Does accessing the object force the user agent to query all (external)
>>> certificate storage mechanisms to discover if any certificates have
>>> been added or removed? I fear under the current language, it does, and
>>> that's not an acceptable solution.
>>> 
>>> Alternatively, it requires the user agent to store within its own
>>> persistence store a static list of all associated certificates with a
>>> key, and that's not a solution I can see as workable either.
>> 
>> I didn't intend either of the above. The intent was that, for these pre-provisioned keys the UA would not even process the certificate - it's just a blob of bytes associated with the key and obtained from the same place the key was obtained from.
> 
> That isn't what I meant.
> 
>> 
>> I think having the UA maintain certificate chains, handle revocation, renewal and do the things above is a whole other topic.
> 
> That wasn't at all what I was suggesting.
> 
>> 
>> I'm assuming that this certificate is pre-provisioned, renewed etc. in the same way as the pre-provisioned key itself, not by the UA.
> 
> And I'm saying that the sources of storage for certificate is
> different than the sources of storage for keys, that there may be more
> certificates than keys, and that certificates may exist in multiple
> storage systems that all have private keys in a single store element.
> 
> As I understand your proposal, you're trying to say that "Only the
> certificate that is stored in the key storage is exposed",

Yes, that is what I'm saying.

> and I don't
> think that's a particularly useful or complete API,

There are certainly many cases it doesn't address. But it's useful for the simplest cases.

> nor do I think
> it's compatible with the asynchronous interfaces being attempted here.

That's an API design issue we can fix.

> For the Key, none of the actual key storage needs to be communicated
> with until a cryptographic operation begins (an asynchronous,
> user-initiated event). The user agent meta-data about how a key can be
> used can (and arguably SHOULD) be stored outside of key storage - in a
> user agent maintained store.
> 
> Your proposal to expose certificates forces one of two things:
> - Every time a Key object is created, the certificate(s) need to be
> discovered from key storage (a blocking operation) and serialized into
> the attribute
> - The browser must cache the value of certificate(s) in browser
> storage after obtaining them from key storage - which creates a cache
> incoherency issue that I suspect is more common in practice than you
> may realize.

I think these things might be true of other attributes, but again this is an API design issue unrelated to the basic proposal to expose this information.

> 
> That's why I object to certificates. I don't see blocking on key
> storage (whether the place the key is directly stored, or all possible
> key storage mechanisms) to discover certificates a viable option, and
> I definitely know from experience that having the browser storage
> cache certificates will lead to incorrect and user-unfriendly results.

Ok, let's make an async API for these things then.

> 
> <snip>
>> I'm more than happy to talk about alternative APIs for exposing the certificate. I would say that I think the problem of exposing a certificate associate with a pre-provisioned key and maintained in the same way as the key itself is an easier task than more general handling for certificates. Particularly because that maintenance is than out of scope for us.
> 
> For the reasons above, I do not believe the pre-provisioned key is any
> different than any other certificate management issues - in fact, the
> issues are at the very heart the same. Coupling it to pre-provisioned
> keys seems like an unnecessary bolt-on.

I'm not sure I agree: there's a simple use-case where all the client application wants to do with the certificate(s) associated with a pre-provisioned key is send them to the application server and then there are more complex cases where the contents of the certificate need to be exposed to the client application. There are cases where certificate maintenance is handled by the same implementation-specific mechanism as the one that handles the pre-provisioning and there are cases where we need to define how a UA does certificate maintenance.

If it's a pre-provisioned key there must therefore be some implementation-specific mechanism that pre-provisioned it - so we can punt the certificate maintenance to that part. For any other kind of key we have no similar option.

I'm ok with addressing everything together, though.

> 
> <snip>
>>> Respectfully, I think the point "If the choices made by implementors
>>> are arbitrary, then this is still useful" is wrong. I think arbitrary
>>> choices make this useless and dangerous to the spec, because it
>>> provides effectively no portability for implementations in terms of
>>> something spec'd in the standard. This is exactly why we're trying to
>>> define, as absolutely and concretely as possible, how RSA, AES, ECC,
>>> etc are performed - so that they're compatible across implementations.
>> 
>> There's an important difference. In the case of all the algorithms, if different implementors made different choices it would be very hard, if not impossible, for me as an application running on those implementations to accommodate those differences.
>> 
>> This is not the case with choice of unique identities. I'm just going to provision those things into my back-end database. It doesn't matter what they are (within reason - if the identity was 2MB in size, that might be a problem), so long as I know their general properties (which I use to inform my offline decision on the authorization and other policies to apply to those devices).
>> 
>> On the other hand, if we don't specify anything, then the choices of attribute will also be arbitrary and that is a problem for me to cope with on the application side.
> 
> Respectfully, you're proposing a solution that we have established, in
> this thread, cannot be compatibly implemented between user agents, is
> not required to be implemented, and, at least as far as user agents
> attempting to use common cryptographic APIs without needing specific
> knowledge of every individual secure element vendor and every
> individual key provisioning scheme, cannot be implemented.

I don't agree this has been established at all.

> 
> I think at the size and scope of our API, we absolutely MUST NOT be
> introducing optional features without strong support within the
> working group, from both implementors and users, as a must have
> feature. We have established, in past threads, that this is absolutely
> something that web developers can standardize independent of the W3C
> process. If we have any hope of shipping a version 1 of this API (or
> even a version 2), then I would again suggest we consider this out of
> scope.

I think you are overstating the scope of the proposal, which I see as a relatively modest one: to recommend a common name for the unique identity which we know must almost always exist for a symmetric pre-provisioned key to be useful at all.

> 
> Considering our exit criteria include multiple interoperable user
> agents implementations, I do not see how this criteria can be met with
> your current proposal - and thus, would block the entire spec from
> progressing. I do not want to see that happen. Without strong support
> from potential user agent implementors (which so far, only Netflix has
> been active in supporting this), it seems very likely that this will
> be the blocking point.

I do agree there is something to discuss here. To date, W3C specifications have mainly dealt with features that are expected to be implemented in relative agile environments, such a desktop browsers. I think it likely that this feature will mainly be implemented in TVs and similar devices and possibly not on desktop browsers (certainly not all). The development cycle for such devices is much longer, which has a consequent effect on our exit criteria.

I don't think it would be acceptable, though, if a feature could be excluded from the specification only on the basis that the implementations expected were in environments with a long development cycle.

> 
> I should note that I also would be very sad to see a "spec" that
> contains 10 optional features, with exit criteria of two compatible
> implementations *per feature*, and having 6 different user agent
> implementations that collectively do not overlap on any two features.
> That, to me, is a complete failure of the WG. I see proposing that
> this be a detachable "feature" of the spec is to encourage that, even
> more than the optional-to-implement algorithm specifications (which
> already suffer from this problem).

Minimizing options is certainly desirable. I don't think you can avoid some options, though, when the spec is targeted at a range of devices with widely varying security properties. Some devices have secure elements, some don't. On some devices the entire software stack is relatively secure on others it is completely open. Some security feature simply can't be implemented in some contexts, but that shouldn't mean they are excluded from our work.

> 
> <snip>
>>> As an implementor, I think the only time the "uid" can be reasonably
>>> exposed then is by Netflix and those working with Netflix.
>> 
>> Well, this set includes all the major TV manufacturers, so we're talking 100s of millions of browser instances by the time this is implemented.
>> 
>> Even accepting your position, you can extend to all other websites that also work with those manufactures, which now includes all the major streaming video providers.
>> 
>>> The
>>> proposed wording provides no guidance whatsoever for Mozilla,
>>> Microsoft, Chromium, Apple, Opera, Intel, or any other potential
>>> implementor.
>> 
>> I disagree - see below.
>> 
>>> It's fully compliant with the spec to not implement it.
>> 
>> Right. That's what optional means ;-)
> 
> And we need fewer optional things.
> 
>> 
>>> It's fully compliant with the spec to implement different things.
>> 
>> Yes and no. All implementations are different in some respects. Probably all distinct implementations of anything in the web platform have different behaviors in some aspect - performance for example - but that doesn't matter from an interoperability perspective except at the extremes.
>> 
>> Similarly the differences in implementation that would be allowed under this proposal don't affect the usefulness of the feature, as I described above.
> 
> Please see above.
>

Received on Tuesday, 30 October 2012 11:13:24 UTC