Re: crypto-ISSUE-25 (Global Unique ID): How do we provision Global Unique ID for pre-provisionned symetric keys [Web Cryptography API]

Hi Mark,

Just a note: Your replies are pretty much unreadable via the web
interface (eg: http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0171.html
), so you might want to check your mail settings for how it's handling
plain-text replies.

On Tue, Aug 21, 2012 at 2:13 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Aug 21, 2012, at 12:48 PM, Ryan Sleevi wrote:
>
> On Tue, Aug 21, 2012 at 12:05 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>
> On Aug 21, 2012, at 11:27 AM, Ryan Sleevi wrote:
>
>
> On Tue, Aug 21, 2012 at 10:51 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>
>
> Mark,
>
>
> While not trying to be dismissive, it remains unclear to me why you
>
> feel that the application-specific, context-specific unique identifier
>
> needs to be more special than any other pre-provisioned attribute.
>
>
> Because the need for such an attribute is neither application- not context-
> specific, as I have explained. All applications with pre-provisioned
> symmetric keys (PSKs) will need such a thing because PSKs are useless
> without it (where useless = no different from keys generated randomly by the
> client).
>
>
> Please note, I am arguing just for this to be supported in the
> specification. It's supported if you have KeyAttributes and the notion that
> some of those may be pre-provisioned along with the key itself. It's not
> supported if you remove KeyAttributes because there's nothing in the Local
> Storage specification about pre-provisioning (and if there was I think the
> link between the key and its attributes would still be too tenuous).
>
>
> I'm fine with Local Storage for attributes that need to be stored by the JS
> application itself.
>
>
>
> As I understand your response, it's primarily (solely?) focused on
>
> pre-provisioned keys, which are already an implementation-specific
>
> detail that is not going to be common across user agents, and is thus
>
> inherently non-portable to begin with.
>
>
> Support for PSKs is essential to our use-case and included in the charter.
>
>
> You are right that not all WebCrypto implementations will support them,
> which just means they are an optional capability. It will need to be
> possible for an application to discover whether a pre-provisioned key
> exists. Applications such as ours will behave differently, depending on
> whether a PSK exists or not.
>
>
> I don't see any mention about PSKs or pre-provisioned keys as being
> part of the charter. That said, no details about the (underlying) key
> storage mechanism are included in the charter, and that was sort of my
> point - that it's an implementation specific detail.
>
>
> The charter states, as a goal, "The provisioning and use of keys within Web
> applications can be used for scenarios like increasing the security of user
> authentication and determining whether a particular device is authenticated
> for particular services."
>
> Ok, so "provisioning" is not qualified as explicitly including
> "pre-provisioning", but without pre-provisioning the goal of device
> authentication is not possible.

I disagree with this assertion.

An application that generated keys that are bound to a device (for
example, how ChromeOS can optionally handle the <keygen> example)
allow for device authentication without any need for pre-provisioning.

I think we can just chalk this up to disagreement about what was meant
by device provisioning, but I can certainly agree that both
interpretations are with merit.

>
> If you look at discussions related to the charting process, for example [2],
> it's clear that pre-provisioned keys were envisaged and that this identity
> requirement was understood. The first and for a long time the only use-case
> submitted for WebCrypto was focussed on the use of pre-provisioned keys.
> They were even discussed (without dissent) at the "Identity in the Browser"
> workshop early last year that kicked off this whole activity.
>
> [2] http://lists.w3.org/Archives/Public/public-identity/2011Dec/0031.html
>
> Given that this is included as a clear goal in our charter I don't think
> it's sufficient to simply say it can all by done by implementations without
> any mention in the specification of how.

Is window.crypto.keys sufficient? If not, what needs to be added?

I'm sorry, but I'm having trouble following whether you're raising a
technical objection - eg: we need a different interface - or simply
one requiring additional supporting text. The former is, I think, more
serious towards the progression of FPWD and has wide impact, least of
all because it can prevent implementation, while the latter I think is
something that we can make forward progress on while hammering out
details.

>
>
> It's in the implementation gray area - there's nothing in LocalStorage
> or in IndexedDB preventing pre-provisioning either. Politics of
> specifying another WG's interface aside, if we accept that
> pre-provisioned keys are a detail that user agents may or may not
> implement, and that the knowledge about whether the keys were or were
> not pre-provisioned relies on the peer (the web application) having
> some out-of-band knowledge, then it seems reasonable to think that the
> user agent and the web application could cooperate on any Web Platform
> API, to the betterment or worsening of the platform.
>
>
> I don't think that's sufficient. The specification needs to say how
> pre-provisioning will look to the script, not least so that the script can
> tell if pre-provisioned keys are present (for its origin).
>
> An application using PSKs will have out-of-band knowledge of those identity
> and key values and properties of the devices they were pre-provisioned into,
> but a script running on a device has no idea what kind of device that is and
> whether it has pre-shared keys. If I have to work with N different ways keys
> and their identities are pre-provisioned for N different devices then I'd
> need to trial-and-error through all those options when starting my script.
> Even if I did know the type of device, I'd have to code N different
> approaches.
>
> So, I don't think it should be left implementation-dependent.
>
>
>
>
> That said, is there any reason why such an ID needs to be any
>
> different from any other pre-provisioned attribute?
>
>
> What other pre-provisioned attributes ?
>
>
> Whatever a user agent that wishes to implement pre-provisioning may support.
>
>
> Ok, so that should be standardized, for the reason above.

I'm having trouble interpreting your response.

Is this a request then that, under ISSUE-17, there be explicit Key Attributes?

Or are you proposing that a new WebIDL needs to be introduced to address this.

>
>
>
> Is this really a
>
> question about unique IDs (as has been framed by yourself and Mitch
>
> several times), or can your need simply be addressed by having
>
> whomever is doing the pre-provisioning of keys (an industry and
>
> application-specific act) also provision those attributes?
>
>
> Where ? As I've said, pre-provisioning of Local Storage is not something
> mentioned in the Local Storage specification and may be viewed as rather
> odd.
>
>
>
> I'd like to focus on this specific point, since I strongly feel the
>
> needs you have identified are already readily addressed by the spec,
>
> and what you're wanting to do is already possible, and without having
>
> to introduce any special handling for pre-provisioned keys, nor
>
> require any language changes to the spec.
>
>
> Could you explain in more detail why you believe that ?
>
>
> I am beginning to feel that we need a specific section on pre-provisioned
> keys, since there's clearly a wide variance in the assumptions people have
> about them.
>
>
> Text welcome at an informative level, but again, I think that
> pre-provisioning is a concept that is inherently non-portable. It may
> simply be sufficient to describe it as "It can happen". Much like the
> only discussion about platform-originated keys (eg: native keys) are
> only mentioned in the Scope section, as informative, and as a
> security/privacy concern. I see pre-provisioned keys as being a
> function of 'native cryptographic module' (eg: they weren't expressly
> requested by the web application), but perhaps that's a semantic
> distinction that isn't shared.
>
>
>
> To be completely unambiguous: pre-provisioned keys are inherently
>
> implementation specific, and thus I believe any attempt to define a
>
> common nomenclature for them is fatally flawed.
>
>
> I disagree. The notion of a pre-provisioned symmetric key with an associated
> identity is straightforward and application-independent and we can easily
> specify is, just as is done for TLS PSK. Just because it is an optional
> feature doesn't make it's definition 'implementation-specific'.
>
>
> In my original message, I provided examples of exactly how it is
> application dependent.
>
>
> And I described why your examples were not quite correct: how a key is
> pre-provisioned is device-manufacturer specific (not application specific).
> How a key identity is shared with an application is an agreement between
> device manufacturer and application provider (you could call that
> application-specific). But what a pre-provisioned key *is* and the fact that
> it needs to be accompanied by an identity, are generic and universal.

I'm sorry, but I believe we're talking past eachother.

Let me try to be clear: Anything that is not part of the user-agent
behaviour, but instead particular to an "application" (in this case,
"Netflix", in their entire client and server implementation and
deployment), is what I call "application specific".

Not every use of pre-provisioned keys is going to rely on device
manufacturers. Therefore, not every pre-provisioned key is
manufacturer specific. For Netflix, every device manufacturer is
responsible for pre-provisioning keys. Therefore, it is
manufacturer-specific. However, because this is specific to Netflix
and the ecosystem of manufacturer relationships they have developed,
and thus not applicable to say, OTR messaging or Google Mail, it is
application-specific.

For something not to be application specific, it needs to apply to
every single consumer of this API, for every possible use case. The
need to represent a Cryptographic Operation is one such example. The
need to represent a Key is (with the exception of hashing), another
such example.

>
> Even the use of TLS PSK is
> application/implementation dependent - the same key identifier used
> for TLS PSK is not necessarily usable for any other purpose, nor is
> the same identifier used by one TLS PSK peer equivalent to the
> identifier used when negotiating (with the same key, if you were that
> dangerous) to another peer.
>
>
> Again, the concept of a PSK and associated identity are sufficiently generic
> that explicit support for the identity is embedded in the TLS PSK
> specification. Yes, a lot of other things are applications specific. I am
> not asking for more than TLS PSK does.
>
>
>
>
> Assume we resolve ISSUE-17 and agree that, indeed, it's necessary to
>
> have a specific attribute store for keys (for which the only use case
>
> I seems to be pre-provisioned keys...). As discussed previously, the
>
> KeyAttributes interface (
>
> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#dfn-KeyAttributes )
>
> fully supports read-only properties. That's why explicit
>
> getters/setters were defined, since WebIDL makes it clear that any
>
> accesses will be redirected through these getters/setters (
>
> http://www.w3.org/TR/WebIDL/ ) and that they need not support the
>
> operation.
>
>
> Yes, if you have the KeyAttributes interface, everything is fine (modulo the
> descriptive text which I think it would be wise to add on this issue). There
> is no need to say what the "name" of the key id is, since whomever
> pre-provisions the id itself can tell me what the name is as well.
>
>
> We could consider keeping KeyAttributes only for functional or read-only
> attributes and require applications to use Local Storage for
> application-specific stuff.
>
>
>
> Possible ways that Netflix can do what they want without a spec change:
>
> * Presume a pre-provisioned Master Key (MK) which is secret from all
>
> applications
>
> * Goal is a pre-provisioned Origin Key (OK), which is origin-specific
>
>
> Option 1: Implicit keys on demand:
>
> - When the UA navigates to one of the authorized origins
>
>   - If an OK does not yet exist, generate one
>
>     - Pre-provision an attribute/value pair with "MKID" and the ID
>
> of the master key
>
>     - Pre-provision an attribute/value pair with "OKID" and whatever
>
> industry-specific origin key
>
>   - Expose it via window.crypto.keys
>
> Option 2: Explicit key derivation
>
> - When the UA navigates to one of the authorized origins
>
>   - Expose the MK as a handle via window.crypto.keys
>
>   - Implement a custom key derivation mechanism ("Netflix-TV-keys")
>
>   - Have your application request that a key be derived from the MK
>
>   - The user agent performs the following steps:
>
>     - Take the origin of the currently executing script (which all
>
> UAs must track anyways), and feed that as input into your derivation
>
> scheme. Thus, it's *never* necessary the application provide it
>
>     - Derive the OK from the MK
>
>     - On the generated OK, set the OKID and MKID as appropriate
>
>     - Return the OK to the application
>
>    - The key is now available to the application, and may be
>
> available later via window.crypto.keys (if the caller requested the OK
>
> be persistent)
>
>
> Both assume that there is a sensible place to pre-provision attributes.
> Local Storage is a sensible place for the application to store stuff, but I
> don't think it works for pre-provisioning key attributes.
>
>
> So then is this just ISSUE-17? It seems the argument is that existing
> storage mechanisms are unsuitable for pre-provisioning, ergo a new
> mechanism is needed. That's a fine argument to make, but does seem to
> get at the heart of ISSUE-17.
>
>
> No, ISSUE-17 says: "For attributes defined by the application, the question
> is…"
>
> So, ISSUE-17 is constrained to attributes defined by the application, which
> I take to mean those where the JS script wants to attach its own attributes
> to a key for later retrieval. If that is the problem, then I agree with your
> arguments that Local Storage seems sufficient.

"Application" represents both the server operator and the executing
client script.

The key is pre-provisioned by the server operator (Netflix), by
contractually delegating that provisioning through to device
manufacturers. Thus, it's "Application specific", but that does not
mean positively or negatively that it may be altered by the content
script executing as part of that application.

>
> The global identity for a pre-shared symmetric key is not one of those
> attributes. It does not start life in the script or even with the
> application-provider. It's pre-provisioned, probably by the device maker.

Who, through relationship with the application-provider, exposes it to
the application provider.

Does every device manufacturer make such keys widely available to
every possible application?

Does every single device on the Internet have such a key?

If not, then I think it is implementation and application specific.

>
> If ISSUE-17 includes pre-provisioned information then I would argue that
> Local Storage is unsuitable for that, unless the Local Storage specification
> is amended to make that use-case clear.

It does, and I think that's a fair comment.

>
>
> That said, the proposal for KeyAttributes being *explicitly* read-only
> is interesting as well. For example, WebIntents does this via the
> 'extras' member of the IntentParameters, which is a key/value map of
> extra meta-data to be sent with the Intent. That said, I understand
> there is some ongoing discussion/controversy regarding it, so it may
> not be the best API to cite.
>
>
> I think both options could work, with some tweaks. If by 'ID of the master
> key' you mean a global id for that, then I would not expect that to be
> exposed. The idea of explicitly exposing a key derivation function that
> factors in the current origin is interesting. That could be under the covers
> (the application only ever knows about the OK), but there may be some
> advantage in giving the application control of the derivation. You'd need to
> derive an orgin-specific key identifier too.
>
>
> In fact if we could specify the above approach that would make things
> significantly easier for device manufacturers.
>
>
> I think that the MK/OK scheme is something specific to a given
> implementation, and highlights both the flexibility and dangers of the
> API.
>
>
> It could be left implementation specific. But we could also decide to
> standardize it if we thought it was generically useful. We don't need to
> have that debate right now.
>
> This similarly relates to the discussions about MUST vs SHOULD
> for algorithms, since the concern was raised that if anyone can
> implement any algorithm, then you'll have new implementations
> effectively barred from entry or working with a site, due to their
> lack of support for a given algorithm.
>
> If we can reach consensus that the fundamental API is flexible enough,
> and possible to standardize, then I think we could begin discussions
> about whether it's worthwhile to specify such a key
> agreement/negotiation scheme that is specific to the context of user
> agents and the security boundaries they operate in (eg: having
> unspoofable inputs from the U-A in addition the the web application's
> inputs). This is similar to the PBKDF2 text in the current draft.
>
> Like all crypto-politics, I imagine that conversation will be a fun
> one, so I would rather wait until we've shipped something (eg: not
> just FPWD) before going down that road.
>
>
>
>
> Again, pre-provisioned keys are user-agent specific.
>
>
> Support of pre-provisioned keys is user-agent-specific. That's different.
>
>
> There is no way
>
> to have pre-provisioned keys to universally work across user agents,
>
> since that universally assumes the same key storage and access APIs,
>
> which is simply impossible. So your user agent can do whatever it
>
> wants - because it's the only one who understands this concept.
>
>
>
> But there are some concepts which are generic, which we can standardize. We
> could standardize the origin-specific key derivation function and the
> concept of a common Master Key as you describe above. We would not make any
> statements about the properties this key has. Some implementations might
> just re-generate it randomly every time. Especially if you're in "incognito
> mode". Others would have it stored in hardware. Doesn't matter because the
> API is not guaranteeing any special properties for this key. Any special
> properties are learned out-of-band.
>
>
> If we had consensus to do so, yes. I don't believe attempting to
> define a new cryptographic algorithm for user agents to derive keys
> from origin inputs is something as an implementor we'd be interested
> in standardizing at this time.
>
>
> OK, let's leave the MK -> OK derivation for later.
>
> …Mark
>

Received on Tuesday, 21 August 2012 21:32:36 UTC