Re: Comments on wrap/unwrap

On Mon, Jun 17, 2013 at 10:55 AM, Ryan Sleevi <sleevi@google.com> wrote:

> On Wed, Jun 12, 2013 at 1:02 PM, Mark Watson <watsonm@netflix.com> wrote:
> >
> >
> > On Wed, Jun 12, 2013 at 12:41 PM, Ryan Sleevi <sleevi@google.com> wrote:
> >>
> >> On Wed, Jun 12, 2013 at 12:24 PM, Mark Watson <watsonm@netflix.com>
> wrote:
> >> >
> >> >
> >> > On Wed, Jun 12, 2013 at 12:00 PM, Ryan Sleevi <sleevi@google.com>
> wrote:
> >> >>
> >> >> On Tue, Jun 11, 2013 at 8:31 AM, Mark Watson <watsonm@netflix.com>
> >> >> wrote:
> >> >> > All,
> >> >> >
> >> >> > First, if you receive two versions of this email, they should be
> >> >> > equivalent.
> >> >> > I wrote one last night and now find no sign of it in my email
> system,
> >> >> > so
> >> >> > this is just a rewrite and retransmission :-(
> >> >> >
> >> >> > Second, sorry for the delay in responding on this topic. I was
> >> >> > unexpectedly
> >> >> > out of the office all last week.
> >> >> >
> >> >> > I have two comments on the wrap/unwrap implementation in the latest
> >> >> > draft.
> >> >> >
> >> >> > 1) The procedures refer to the import/export procedures which are
> >> >> > currently
> >> >> > unspecified. For the mechanism to meet the original requirements,
> >> >> > it's
> >> >> > important that import and export respect the attributes of the Key
> >> >> > (usage,
> >> >> > exportable). We need to define mappings for these to/from JWK and
> in
> >> >> > the
> >> >> > import case the values in the JWK must override those in the import
> >> >> > method
> >> >> > parameters.
> >> >>
> >> >> I'm of a mixed opinion as to whether or not this needs to be
> specified
> >> >> to this level. The security model assumed here is already
> >> >> implementation dependent - whether or an implementation respects
> these
> >> >> fields, or provides any other guarantees, is already opaque to the
> web
> >> >> application.
> >> >
> >> >
> >> > You could also say that about the extractable attribute, or
> potentially
> >> > anything in the spec. The spec defines what a compliant implementation
> >> > must
> >> > do and there is some value in that even when you don't have 100% proof
> >> > that
> >> > the UA is compliant.
> >> >
> >> > To support the use-case, this needs to be specified as proposed.
> >> >
> >> >>
> >> >>
> >> >> >
> >> >> > 2) There is one important difference between our proposal and what
> >> >> > Ryan
> >> >> > has
> >> >> > implemented. We proposed methods that would create/consume a
> >> >> > JWE-encrypted
> >> >> > JWK object in one step. Ryan's proposed methods are simpler, more
> >> >> > flexible
> >> >> > and agnostic as to the wrapping format. Implementing JWE-encrypted
> >> >> > JWK
> >> >> > takes
> >> >> > two steps but the JS could also implement other formats.
> >> >> >
> >> >> > However, in order to obtain the same properties, in terms of key
> >> >> > extractibility, as the original proposal it is necessary for any
> >> >> > temporary
> >> >> > keys (such as JWE Content Encryption Key) to be encoded in a way
> that
> >> >> > carries attributes. To explain this, first note that Ryan's methods
> >> >> > wrap
> >> >> > and
> >> >> > unwrap are effectively compound methods based on the existing
> >> >> > encrypt,
> >> >> > decrypt, import and export: wrap = export+encrypt and
> >> >> > unwrap=decrypt+import
> >> >> > where the intermediate result (at the '+') is not exposed to the
> >> >> > script.
> >> >> >
> >> >> > To implement JWE-encrypted JWK with these methods we proceed as
> >> >> > follows:
> >> >> >
> >> >> > Wrap a key X using wrapping key Y:
> >> >> > (W1) Generate a Content Encryption Key with usage "wrap"
> >> >> > (W2) Use the CEK with the wrap method to export+encrypt X (using
> JWK
> >> >> > format)
> >> >> > (W3) Use Y and with the wrap method to export+encrypt the CEK
> >> >> > (W3) Construct the JWE object using the output of steps W2 and W3
> >> >> >
> >> >> > Unwrap a key X using wrapping key Y:
> >> >> > (U1) Extract the wrapped CEK and the payload from the JWE structure
> >> >> > (U2) Use Y and the unwrap method to decrypt+import the wrapped CEK,
> >> >> > resulting in a Key object K[CEK] for the CEK
> >> >> > (U3) Use K[CEK] and the unwrap method to decrypt+import the
> payload,
> >> >> > resulting in a Key object for X
> >> >> >
> >> >> > Let's suppose the X has extractable=false. In order for this
> property
> >> >> > to
> >> >> > be
> >> >> > maintained it's essential the K[CEK] is not extractible and does
> not
> >> >> > have
> >> >> > usage "decrypt". Otherwise, it would be possible for the Javascript
> >> >> > to
> >> >> > use
> >> >> > K[CEK] to simply decrypt the payload, exposing the key X.
> >> >> >
> >> >> > Therefore, the wrapped encoding of the CEK must carry the
> extractible
> >> >> > and
> >> >> > usages attributes (for cases where the extractibility property of X
> >> >> > must
> >> >> > be
> >> >> > maintained).
> >> >>
> >> >> I don't really see this as the case.
> >> >>
> >> >> Again, you're working from a threat model where you don't trust the
> >> >> executing JS. Obviously, this is a threat model that I disagree with,
> >> >> but you can mitigate this in an implementation-dependent way that
> >> >> matches your implementation-dependent dependency on named keys.
> >> >
> >> >
> >> > We can't, because this is an issue also without named keys.
> >> >
> >> > Regarding the security model, we previously established that this is
> an
> >> > issue and that it affects the extractable attribute as much as these
> >> > other
> >> > things. We should keep the specification consistent - if we are going
> to
> >> > have the extractable attribute at all then we need to be able to
> deliver
> >> > non-extractable wrapped keys, which has the implications I described
> >> > above.
> >> >
> >> > If the group decides that the model is invalid, then the extractable
> >> > attribute can be removed and my points above become moot.
> >>
> >> I disagree with your conclusion that supporting extractable requires,
> >> by definition supporting non-extractable wrapped keys - if anything,
> >> this highlights the general issue with key wrapping.
> >
> >
> > No, that wasn't what I was getting at.
> >
> > We have extractable in the specification. It makes sense to have it there
> > only if you accept that there is some value in hiding keys from the JS.
> So,
> > let's just say that as long as extractable is in the specification there
> is
> > some value in hiding keys from the JS. We have a separate issue to
> decide on
> > that point, but for the moment, extractable is in the specification.
> >
> > If it is valuable to hide keys from the JS, it's also valuable to deliver
> > wrapped keys into the UA in such a way that they remain hidden from the
> JS.
> > That was the main point of our wrap/unwrap proposal which the group
> agreed
> > should be implemented in the specification, albeit as a "feature at
> risk".
> >
> >>
> >> Your proposed solution suggests that the JWE/CEK should be modified to
> >> support attributes - which helps for the JWE/CEK case, but does
> >> nothing for other formats, which would conceivably share the same
> >> issue.
> >
> >
> > No, *your* proposed implementation of wrap/unwrap - in which we require
> two
> > operations to implement JWE-encapsulated JWK - implies that the CEK must
> > carry attributes to maintain the properties of the original proposal (to
> > which the group agreed).
> >
> > Other formats may also have the same problem: if the wrapping operation
> is a
> > single operation, then there is no need for the temporary keys that must
> > necessarily be used when wrapping using public key cryptography to carry
> > separate attributes. It is the splitting into two operations, which is
> > certainly elegant in the sense of decoupling from the specific wrapping
> > format, that introduces the requirement for attributes on the temporary
> key.
> > At least in the model where you don't which to expose the wrapped key to
> the
> > JS.
> >
> > What we end up with is a solution which can support any wrapping format
> > (good), but only wrapping formats with attributed-carrying temporary keys
> > will be able to keep keys hidden from the JS.
> >
> > I'm fine with this, btw.
>
> Mark,
>
> I fail to see how you reach the conclusion of an attribute-carrying
> temporary key being necessary, especially given the following examples
> of other APIs.
>

Ok, I'll state it again. Suppose you have a JWE-wrapped JWK and the payload
key is supposed to be non-extractable.

My first step to unwrap the CEK, resulting in a Key object K[CEK]. Then I
can unwrap the payload using K[CEK]. To maintain the non-extractability of
the payload key, I need the following to be true:
(1) K[CEK] does not have usage "decrypt"
(2) K[CEK] is non-extractable

The reasons for these requirements are, (1) if K[CEK] has usage "decrypt" I
can use it to decrypt the payload JWK, exposing the key material to JS and
(2) if K[CEK] is extractable, I can just export it and re-import it with
usage "decrypt".

So, how do we ensure (1) and (2). There are only two options:
(a) something in the CEK format causes the attributes to be set this way.
For example the CEK actually carries attributes and these are respected
during the upwrap into K[CEK]
(b) some special properties of the unwrapping key used to unwrap the CEK
cause K[CEK] to obey (1) and (2)

You've argued (b) could apply for named keys, but I don't see how (b) could
work for ordinary WebCrypto keys without extension to the Key API.

For (a), one could imagine simply assuming (1) and (2) always for all
formats, or for all formats that don't explicitly carry attributes, but I
don't feel this is especially elegant. Hence the conclusion that attributes
must be supported.

Note that I am not saying that *only* formats with attributes must be
supported, just that we need to specify this case.


>
> >
> >>
> >>
> >> CryptoAPI/CNG, for example (and +cc Vijay for the possibility of me
> >> misstating here) lacks the functionality you're requesting, and has
> >> worked out quite fine for applications.
> >>
> >> PKCS#11 somewhat supports the notion you're trying for, by virtue of
> >> the CKA_WRAP_TEMPLATE and CKA_UNWRAP_TEMPLATE attribute that applies
> >> to the wrap/unwrapping key. In the wrap case, the CKA_WRAP_TEMPLATE
> >> specifies a list of attributes that the *key to be wrapped* must
> >> match. In the unwrap case, the CKA_UNWRAP_TEMPLATE specifies a list of
> >> attributes that must not conflict with the caller-supplied list of
> >> attributes.
> >>
> >> My statement about the unwrapping key rejecting extractable=false is a
> >> failure mode consistent with this latter part. The issue you have
> >> seems to be whether or not the ability to mutate those attributes
> >> necessarily needs to be exposed to application authors, or whether it
> >> can be kept behind the notion of 'implementation dependent' - for
> >> example, coupled to named keys.
> >
> >
> > Yes, this is another option, in which the unwrapping key carries
> additional
> > attributes not just about its own extractability/usages but about the
> > extractability/usages of keys that it unwraps. We would require a new
> > UnwrappingKey subclass that exposed these attributes, a way to set them
> when
> > generating keys and a mapping of these attributes to JWK. We need this
> > functionality for the case where there are no named origin-specific keys
> > (the TOFU case).
> >
> > I don't feel this is especially elegant. It seems unnecessarily complex
> when
> > the solution requiring the format to support attributes on the CEK is
> fine
> > for the use-cases at hand.
> >
> > Another possibility, which is even less elegant but also less complex, is
> > that when unwrapping keys in a format without attributes, the attributes
> of
> > the unwrapping key are simply copied to the unwrapped key (I did say this
> > was even less elegant ...).
>
> I think it's fundamentally a mistake to attempt to solve this problem
> generically at this time, which is part of why I've highlighted from
> the beginning the issues with wrapping and unwrapping.
>

Can you explain why you think this ?


>
> I don't think it necessarily requires a new UnwrappingKey subclass,
> nor of the mapping to JWK. I suspect there's probably some interim
> steps in how you see this process working that I'm missing, because it
> does not seem self-evident.
>

I hope the above clarifies.


>
> I do not see requiring the format to support attributes on the CEK
> being acceptable for the API


I mean that the specification should include a format with attributes and a
requirement that attributes when specified must be respected.

Of course, if you want to use CEK formats without attributes this should
also work, but you won't be able to maintain non-extractability.


> , even if it will meet Netflix's specific
> use case. We should specifically be avoiding both coupling the API to
> any particular format


With respect to key wrapping formats, agreed. JWK is on of the key export
formats we've already decided to support.


> AND inventing our own formats, which such a
> solution requires.
>

Except that we need to define mapping from WebCrypto Key attributes to/from
JWK.


>
> >
> >>
> >>
> >> I don't think it's absolutely necessary for non-extractable unwrapped
> >> keys to be supported in V1.
> >
> >
> > I do. It was almost the whole point of the original proposal. Let's see
> what
> > the rest of the group thinks.
> >
> > ...Mark
>
> Again, I'm proposing a solution that attempts to solve a middle-ground
> in the quest for a generic long-term solution.


> It allows for unextractable to be set for keys generated through the
> API, and permits implementations using the key discovery API (which
> is, inherently, as "implementation specific" as APIs such as EME) to
> provide a different set of guarantees.
>

Yep, but this doesn't address the base specification case, without named
keys, as discussed on the call.


>
> I think we need to be extremely careful about trying to shove too much
> into V1, and I also think we must remain very aware of the fact that
> this particular feature you're requesting is one that is not at all
> common in the crypto libraries existing user agents are using - which
> was part of the whole motivation from this groups formation.
>

I think we *are* being extremely careful. We've been working on wrap/unwrap
for many months. The group agreed after long discussion to put the proposal
into the specification, but it has only be partially implemented. There are
multiple independent implementations of our original proposal and so it's
probably far better vetted than some other aspects of the specification.

...Mark