This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24457 - AES-KW can only wrap a JWK key if its serialization happens to be 8*n bytes long
Summary: AES-KW can only wrap a JWK key if its serialization happens to be 8*n bytes long
Status: RESOLVED FIXED
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ryan Sleevi
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-31 20:20 UTC by Alexey Proskuryakov
Modified: 2014-03-07 00:41 UTC (History)
1 user (show)

See Also:


Attachments

Description Alexey Proskuryakov 2014-01-31 20:20:58 UTC
Per RFC3394,

   The inputs to the key wrapping process are the KEK and the plaintext
   to be wrapped.  The plaintext consists of n 64-bit blocks, containing
   the key data being wrapped.

JWK serialization of a key can have an arbitrary length, so it's not a suitable input for key wrapping.

WebCrypto spec needs to define some way to resolve this (e.g. the implementation would pad the UTF-8 serialized string with 0x20 bytes).

Thinking about which, the spec doesn't even seem to say how JWK is serialized for wrapping.
Comment 1 Mark Watson 2014-01-31 21:40:22 UTC
(In reply to Alexey Proskuryakov from comment #0)
> Per RFC3394,
> 
>    The inputs to the key wrapping process are the KEK and the plaintext
>    to be wrapped.  The plaintext consists of n 64-bit blocks, containing
>    the key data being wrapped.
> 
> JWK serialization of a key can have an arbitrary length, so it's not a
> suitable input for key wrapping.
> 
> WebCrypto spec needs to define some way to resolve this (e.g. the
> implementation would pad the UTF-8 serialized string with 0x20 bytes).

It's true that the wrapKey operation with AES-KW will succeed only if the serialized key is a multiple of 8 bytes. This is a restriction of RFC3394.

There were strong objections to the idea of defining a new padding scheme in WebCrypto. If we want an AES-KW algorithm that supports padding we should use the standard one in RFC5649. But there were objections to referencing that specification too based on library support.

I would note that it is relatively easy for an implementation to generate a value JWK which is a multiple of 8 bytes in length, since JSON allows for arbitrary whitespace between tokens. There is no need to standardize such behaviour since the result is still just JSON.

> 
> Thinking about which, the spec doesn't even seem to say how JWK is
> serialized for wrapping.

This is addressed in 20611
Comment 2 Alexey Proskuryakov 2014-01-31 23:21:39 UTC
> I would note that it is relatively easy for an implementation to generate a
> value JWK which is a multiple of 8 bytes in length, since JSON allows for
> arbitrary whitespace between tokens. There is no need to standardize such
> behaviour since the result is still just JSON.

A non-WebCrypto implementation that wraps a key for WebCrypto to use can do that.

So, WebCrypto unwrap is fine, but WebCrypto wrap is not.
Comment 3 Mark Watson 2014-01-31 23:57:24 UTC
(In reply to Alexey Proskuryakov from comment #2)
> > I would note that it is relatively easy for an implementation to generate a
> > value JWK which is a multiple of 8 bytes in length, since JSON allows for
> > arbitrary whitespace between tokens. There is no need to standardize such
> > behaviour since the result is still just JSON.
> 
> A non-WebCrypto implementation that wraps a key for WebCrypto to use can do
> that.

Why can't a WebCrypto implementation do that ? There is nothing in the export procedures that says the JSON output must be free of whitespace (inside the object). We only say (well, imply) that the output must be valid JSON, which it would be.


> 
> So, WebCrypto unwrap is fine, but WebCrypto wrap is not.

I don't think the specification gives users any confidence that they can rely on wrap of a JWK with AES-KW to work. But that doesn't stop implementations being made where it does, in fact, work.
Comment 4 Ryan Sleevi 2014-02-01 00:08:17 UTC
(In reply to Mark Watson from comment #3)
> (In reply to Alexey Proskuryakov from comment #2)
> > > I would note that it is relatively easy for an implementation to generate a
> > > value JWK which is a multiple of 8 bytes in length, since JSON allows for
> > > arbitrary whitespace between tokens. There is no need to standardize such
> > > behaviour since the result is still just JSON.
> > 
> > A non-WebCrypto implementation that wraps a key for WebCrypto to use can do
> > that.
> 
> Why can't a WebCrypto implementation do that ? There is nothing in the
> export procedures that says the JSON output must be free of whitespace
> (inside the object). We only say (well, imply) that the output must be valid
> JSON, which it would be.
> 
> 
> > 
> > So, WebCrypto unwrap is fine, but WebCrypto wrap is not.
> 
> I don't think the specification gives users any confidence that they can
> rely on wrap of a JWK with AES-KW to work. But that doesn't stop
> implementations being made where it does, in fact, work.

Note that the NIST definition of AES-KW notes that key data that is not a multiple of 64 bits may require alternative definitions of the Initial Value to achieve the desired Integrity values.

This is equally reflected in the AES-KW RFC (RFC 3394).

You're right that implementations can choose to diverge from existing cryptographic standards, but do so at the risk to themselves and their users.

I would like to see this addressed in the spec.
Comment 5 Mark Watson 2014-02-01 00:21:03 UTC
(In reply to Ryan Sleevi from comment #4)
> (In reply to Mark Watson from comment #3)
> > (In reply to Alexey Proskuryakov from comment #2)
> > > > I would note that it is relatively easy for an implementation to generate a
> > > > value JWK which is a multiple of 8 bytes in length, since JSON allows for
> > > > arbitrary whitespace between tokens. There is no need to standardize such
> > > > behaviour since the result is still just JSON.
> > > 
> > > A non-WebCrypto implementation that wraps a key for WebCrypto to use can do
> > > that.
> > 
> > Why can't a WebCrypto implementation do that ? There is nothing in the
> > export procedures that says the JSON output must be free of whitespace
> > (inside the object). We only say (well, imply) that the output must be valid
> > JSON, which it would be.
> > 
> > 
> > > 
> > > So, WebCrypto unwrap is fine, but WebCrypto wrap is not.
> > 
> > I don't think the specification gives users any confidence that they can
> > rely on wrap of a JWK with AES-KW to work. But that doesn't stop
> > implementations being made where it does, in fact, work.
> 
> Note that the NIST definition of AES-KW notes that key data that is not a
> multiple of 64 bits may require alternative definitions of the Initial Value
> to achieve the desired Integrity values.
> 
> This is equally reflected in the AES-KW RFC (RFC 3394).
> 
> You're right that implementations can choose to diverge from existing
> cryptographic standards, but do so at the risk to themselves and their users.
> 
> I would like to see this addressed in the spec.

What exactly would you like to see addressed ?

I am not suggesting that the input to RFC3394 diverge from requirement to be a multiple of 64 bits. I am also not suggesting that the input be anything other than a valid JSON string. I am not suggesting padding at the end of that string either(either zeros or spaces).

All I am suggesting is that when you serialize a JSON object, where the first character is '{' and the last is '}', it is still rather easy to ensure there are a multiple of 8 characters.
Comment 6 Ryan Sleevi 2014-02-01 00:39:13 UTC
(In reply to Mark Watson from comment #5)
> (In reply to Ryan Sleevi from comment #4)
> > (In reply to Mark Watson from comment #3)
> > > (In reply to Alexey Proskuryakov from comment #2)
> > > > > I would note that it is relatively easy for an implementation to generate a
> > > > > value JWK which is a multiple of 8 bytes in length, since JSON allows for
> > > > > arbitrary whitespace between tokens. There is no need to standardize such
> > > > > behaviour since the result is still just JSON.
> > > > 
> > > > A non-WebCrypto implementation that wraps a key for WebCrypto to use can do
> > > > that.
> > > 
> > > Why can't a WebCrypto implementation do that ? There is nothing in the
> > > export procedures that says the JSON output must be free of whitespace
> > > (inside the object). We only say (well, imply) that the output must be valid
> > > JSON, which it would be.
> > > 
> > > 
> > > > 
> > > > So, WebCrypto unwrap is fine, but WebCrypto wrap is not.
> > > 
> > > I don't think the specification gives users any confidence that they can
> > > rely on wrap of a JWK with AES-KW to work. But that doesn't stop
> > > implementations being made where it does, in fact, work.
> > 
> > Note that the NIST definition of AES-KW notes that key data that is not a
> > multiple of 64 bits may require alternative definitions of the Initial Value
> > to achieve the desired Integrity values.
> > 
> > This is equally reflected in the AES-KW RFC (RFC 3394).
> > 
> > You're right that implementations can choose to diverge from existing
> > cryptographic standards, but do so at the risk to themselves and their users.
> > 
> > I would like to see this addressed in the spec.
> 
> What exactly would you like to see addressed ?
> 
> I am not suggesting that the input to RFC3394 diverge from requirement to be
> a multiple of 64 bits. I am also not suggesting that the input be anything
> other than a valid JSON string. I am not suggesting padding at the end of
> that string either(either zeros or spaces).
> 
> All I am suggesting is that when you serialize a JSON object, where the
> first character is '{' and the last is '}', it is still rather easy to
> ensure there are a multiple of 8 characters.

This is part of my general concern with the suitability of JWK/JSON as the exchange format, but I would like to see there be a strongly typed, single, canonical format. That is, defined such that all unnecessary whitespace is eliminated, all line breaks are removed, etc - and it be a failure otherwise.

I'm not suggesting this is required for importKey. However, in the context of wrapping, it's deeply troubling to allow attackers the ability to insert arbitrary content - through the use of whitespace characters or, potentially, through the use of any fields that are "ignored".

Such a definition - while good for security - would explicitly prohibit a solution that I believe you're implying, but not stating - such as using whitespace between fields within the JWK. In such a "minimal form required - for input *and* output", it is NOT rather easy to ensure there are multiples of 8 characters.
Comment 7 Mark Watson 2014-02-01 06:14:07 UTC
I think it was more than just an implication, but anyway, yes, inserting whitespace between fields would be one way.

Your point about the security implications of the absence of a canonical format for JWK probably belongs in the JOSE group. JWK has been in our specification for a *long* time and been worked on in the IETF for an equally long time and it's been experimented with to the extent that there are commercial services using wrapped JWK in the field. So, whilst I understand what you are saying I think that if your concern is valid it would be best addressed first in JOSE and - depending on the outcome there - by including something better in a future version of WebCrypto.
Comment 8 Ryan Sleevi 2014-02-01 07:32:37 UTC
(In reply to Mark Watson from comment #7)
> I think it was more than just an implication, but anyway, yes, inserting
> whitespace between fields would be one way.
> 
> Your point about the security implications of the absence of a canonical
> format for JWK probably belongs in the JOSE group. JWK has been in our
> specification for a *long* time and been worked on in the IETF for an
> equally long time and it's been experimented with to the extent that there
> are commercial services using wrapped JWK in the field. So, whilst I
> understand what you are saying I think that if your concern is valid it
> would be best addressed first in JOSE and - depending on the outcome there -
> by including something better in a future version of WebCrypto.

Sorry, you're wrong for suggesting this belongs in JOSE, because this is not an issue of JOSE's creation - this is entirely due to WebCrypto specifying AES-KW for generic use with wrapping JWKs, and not just CEKs, specifically in order to satisfy a request of Netflix.

JOSE avoids this entirely by wrapping CEKs with AES-KW, not an overall JWK product. If we as a WG are going to suggest that its use is acceptable beyond that of a CEK - eg: in order to support attributes like extractability - then we must deal with the security issues that we as a WG are introducing.
Comment 9 Mark Watson 2014-02-06 20:31:12 UTC
(In reply to Ryan Sleevi from comment #8)
> (In reply to Mark Watson from comment #7)
> > I think it was more than just an implication, but anyway, yes, inserting
> > whitespace between fields would be one way.
> > 
> > Your point about the security implications of the absence of a canonical
> > format for JWK probably belongs in the JOSE group. JWK has been in our
> > specification for a *long* time and been worked on in the IETF for an
> > equally long time and it's been experimented with to the extent that there
> > are commercial services using wrapped JWK in the field. So, whilst I
> > understand what you are saying I think that if your concern is valid it
> > would be best addressed first in JOSE and - depending on the outcome there -
> > by including something better in a future version of WebCrypto.
> 
> Sorry, you're wrong for suggesting this belongs in JOSE, because this is not
> an issue of JOSE's creation - this is entirely due to WebCrypto specifying
> AES-KW for generic use with wrapping JWKs, and not just CEKs, specifically
> in order to satisfy a request of Netflix.
> 
> JOSE avoids this entirely by wrapping CEKs with AES-KW, not an overall JWK
> product. If we as a WG are going to suggest that its use is acceptable
> beyond that of a CEK - eg: in order to support attributes like
> extractability - then we must deal with the security issues that we as a WG
> are introducing.

This is a separate issue from the subject of this bug: you're saying that the lack of a canonical representation of the cleartext JWK introduces a security issue that does not exist when wrapping a fixed-length, canonical, CEK.

If this is an issue, it exists for any wrapping of a JWK, not just using AES-KW. There is no canonical plaintext when wrapping a JWK with RFC5649 or AES-GCM or when using JWE to wrap a JWK as recommended by JOSE. Now, the issue may be less severe where there is stronger integrity protection, but AES-KW is not without integrity protection.

So, I still believe the lack of a canonical representation is an issue for JOSE if indeed it is an issue at all. If the fact that AES-KW integrity protection is weaker than the other methods is the issue, then we can note this: I certainly would think anyone using AES-KW would want to migrate to something better as soon as it is available. Indeed, I think the solution to the problem here is not to define a canonical format for JWK but to use a better key wrap: AES-GCM or JWE (as we originally proposed, btw).
Comment 10 Ryan Sleevi 2014-02-06 21:07:20 UTC
(In reply to Mark Watson from comment #9)
> (In reply to Ryan Sleevi from comment #8)
> > (In reply to Mark Watson from comment #7)
> > > I think it was more than just an implication, but anyway, yes, inserting
> > > whitespace between fields would be one way.
> > > 
> > > Your point about the security implications of the absence of a canonical
> > > format for JWK probably belongs in the JOSE group. JWK has been in our
> > > specification for a *long* time and been worked on in the IETF for an
> > > equally long time and it's been experimented with to the extent that there
> > > are commercial services using wrapped JWK in the field. So, whilst I
> > > understand what you are saying I think that if your concern is valid it
> > > would be best addressed first in JOSE and - depending on the outcome there -
> > > by including something better in a future version of WebCrypto.
> > 
> > Sorry, you're wrong for suggesting this belongs in JOSE, because this is not
> > an issue of JOSE's creation - this is entirely due to WebCrypto specifying
> > AES-KW for generic use with wrapping JWKs, and not just CEKs, specifically
> > in order to satisfy a request of Netflix.
> > 
> > JOSE avoids this entirely by wrapping CEKs with AES-KW, not an overall JWK
> > product. If we as a WG are going to suggest that its use is acceptable
> > beyond that of a CEK - eg: in order to support attributes like
> > extractability - then we must deal with the security issues that we as a WG
> > are introducing.
> 
> This is a separate issue from the subject of this bug: you're saying that
> the lack of a canonical representation of the cleartext JWK introduces a
> security issue that does not exist when wrapping a fixed-length, canonical,
> CEK.
> 
> If this is an issue, it exists for any wrapping of a JWK, not just using
> AES-KW. There is no canonical plaintext when wrapping a JWK with RFC5649 or
> AES-GCM or when using JWE to wrap a JWK as recommended by JOSE. Now, the
> issue may be less severe where there is stronger integrity protection, but
> AES-KW is not without integrity protection.
> 
> So, I still believe the lack of a canonical representation is an issue for
> JOSE if indeed it is an issue at all. If the fact that AES-KW integrity
> protection is weaker than the other methods is the issue, then we can note
> this: I certainly would think anyone using AES-KW would want to migrate to
> something better as soon as it is available. Indeed, I think the solution to
> the problem here is not to define a canonical format for JWK but to use a
> better key wrap: AES-GCM or JWE (as we originally proposed, btw).

You're right that AES-KW is not without (some) integrity protection, but as I explained above, the integrity protection is entirely relative to the content, and in particular, presumes that there is no "meaningless" data, and if there is, that users of AES-KW should choose their own (alternative) integrity protection. Which, because WebCrypto is (presently) suggesting the use of AES-KW with JWK, we need to do. Padding does not absolve us of that security requirement (nor does the AES-KW-PAD method)

AES-KW is useful, particularly with 'raw' keys, so I'm not suggesting removing it. I definitely have serious reservations for suggesting it can be safely/reliably used with respect to JWK in a 'non-canonical' form, since JSON parsers are incredibly liberal in their checking, so I am more inclined to suggest that the use of AES-KW (and/or AES-KW-PAD) should be forbidden with JWK outright.
Comment 11 Mark Watson 2014-02-06 21:50:22 UTC
(In reply to Ryan Sleevi from comment #10)
> 
> You're right that AES-KW is not without (some) integrity protection, but as
> I explained above, the integrity protection is entirely relative to the
> content, and in particular, presumes that there is no "meaningless" data,

I'm not sure I understand what you mean here, unless you are just pointing out that the integrity protection protects the n*8 byte AES-KW payload as distinct from protecting just the key data itself ?

That is, that the absence of a canonical representation for the key data gives an attacker wishing to construct a value that passes integrity protection more to play with ?

> and if there is, that users of AES-KW should choose their own (alternative)
> integrity protection.

There's no such recommendation. What the spec says is that if you want to have the integrity protection also cover data that is not in the payload, or if you want it to cover only part of the payload (because the payload was not a multiple of 8 bytes), then you *can* do that by choosing a different IV. And that implementations should support that. I'm not sure how either of those things work, btw.

 Which, because WebCrypto is (presently) suggesting the
> use of AES-KW with JWK, we need to do. Padding does not absolve us of that
> security requirement (nor does the AES-KW-PAD method)

I am missing why the situation is any different from AES-GCM, for example ?

> 
> AES-KW is useful, particularly with 'raw' keys, so I'm not suggesting
> removing it. I definitely have serious reservations for suggesting it can be
> safely/reliably used with respect to JWK in a 'non-canonical' form, since
> JSON parsers are incredibly liberal in their checking, so I am more inclined
> to suggest that the use of AES-KW (and/or AES-KW-PAD) should be forbidden
> with JWK outright.

I don't think you've demonstrated any basis for such a change.
Comment 12 Ryan Sleevi 2014-02-06 22:18:22 UTC
(In reply to Mark Watson from comment #11)
> (In reply to Ryan Sleevi from comment #10)
> > 
> > You're right that AES-KW is not without (some) integrity protection, but as
> > I explained above, the integrity protection is entirely relative to the
> > content, and in particular, presumes that there is no "meaningless" data,
> 
> I'm not sure I understand what you mean here, unless you are just pointing
> out that the integrity protection protects the n*8 byte AES-KW payload as
> distinct from protecting just the key data itself ?
> 
> That is, that the absence of a canonical representation for the key data
> gives an attacker wishing to construct a value that passes integrity
> protection more to play with ?

AES-KW protects an n*8 byte key in which all data is part of the key. The spec is clear to call out situations of an AES key, but also cases with DH key. Both of these keys are octet sequences.

The use of AES-KW with JWK is a mashup of mental models - it's not strictly a key data, but a structured data with generatl encryption. For this, AES-KW is not ideal, much in the same way that "RAW AES" is not ideal.

SP 800-38F is much more verbose on the security assurances provided - and the absence of proofs of strength and criticisms.

> 
> > and if there is, that users of AES-KW should choose their own (alternative)
> > integrity protection.
> 
> There's no such recommendation. What the spec says is that if you want to
> have the integrity protection also cover data that is not in the payload, or
> if you want it to cover only part of the payload (because the payload was
> not a multiple of 8 bytes), then you *can* do that by choosing a different
> IV. And that implementations should support that. I'm not sure how either of
> those things work, btw.
> 
>  Which, because WebCrypto is (presently) suggesting the
> > use of AES-KW with JWK, we need to do. Padding does not absolve us of that
> > security requirement (nor does the AES-KW-PAD method)
> 
> I am missing why the situation is any different from AES-GCM, for example ?

Because the authentication tag offers (more) robust assurances of the non-equivalence.

> 
> > 
> > AES-KW is useful, particularly with 'raw' keys, so I'm not suggesting
> > removing it. I definitely have serious reservations for suggesting it can be
> > safely/reliably used with respect to JWK in a 'non-canonical' form, since
> > JSON parsers are incredibly liberal in their checking, so I am more inclined
> > to suggest that the use of AES-KW (and/or AES-KW-PAD) should be forbidden
> > with JWK outright.
> 
> I don't think you've demonstrated any basis for such a change.

You're arguing for implementing application-specific padding schemes because
1) Implementations don't support AES-KW-PAD
2) You wish to use AES-KW with non-aligned data

I'm objecting, because the security properties of AES-KW are derived from:
1) Assuming that the entire message is semantically the key (that is, NOT structured data that describes the key)
2) The key being the exact block size multiple

Our fundamental disagreement is on whether or not AES-KW provides suitable security guarantees under your proposed modifications.

* If not (as I assert), we should discourage or, arguably, forbid it - because there's no *existing* impls supporting the combination proposed, so there's no "legacy compat" issue.
* If so (as you assert), it's fine.

I think the burden of proof is on demonstrating its security, especially under the proposed interpretations (eg: space padding), otherwise there's no compelling reason to allow it. In the face of disagreement, the safe/good option is to disallow it.
Comment 13 Mark Watson 2014-02-06 22:36:28 UTC
(In reply to Ryan Sleevi from comment #12)
> (In reply to Mark Watson from comment #11)
> > (In reply to Ryan Sleevi from comment #10)
> > > 
> > > AES-KW is useful, particularly with 'raw' keys, so I'm not suggesting
> > > removing it. I definitely have serious reservations for suggesting it can be
> > > safely/reliably used with respect to JWK in a 'non-canonical' form, since
> > > JSON parsers are incredibly liberal in their checking, so I am more inclined
> > > to suggest that the use of AES-KW (and/or AES-KW-PAD) should be forbidden
> > > with JWK outright.
> > 
> > I don't think you've demonstrated any basis for such a change.
> 
> You're arguing for implementing application-specific padding schemes because
> 1) Implementations don't support AES-KW-PAD
> 2) You wish to use AES-KW with non-aligned data

Actually, I just want a way to wrap JWKs. I don't really mind what it is. But AES-KW has turned out to be the only option right now.

> 
> I'm objecting, because the security properties of AES-KW are derived from:
> 1) Assuming that the entire message is semantically the key (that is, NOT
> structured data that describes the key)
> 2) The key being the exact block size multiple

I'll read the document you referenced, but I'll note that there is nothing in the RFC that indicates the assumption (1).

Can you explain, though, why this problem would not apply also to AES-KW with padding (RFC5649) ? Or are you assuming that if we had that we would use a canonical JWK encoding ?

> 
> Our fundamental disagreement is on whether or not AES-KW provides suitable
> security guarantees under your proposed modifications.
> 

I guess 'suitable' depends on the application and so isn't really for us to say - unless it's likely unsuitable for _all_ applications.

> * If not (as I assert), we should discourage or, arguably, forbid it -
> because there's no *existing* impls supporting the combination proposed, so
> there's no "legacy compat" issue.
> * If so (as you assert), it's fine.
> 
> I think the burden of proof is on demonstrating its security, especially
> under the proposed interpretations (eg: space padding), otherwise there's no
> compelling reason to allow it. In the face of disagreement, the safe/good
> option is to disallow it.

In favor of what ?
Comment 14 Ryan Sleevi 2014-02-07 02:15:49 UTC
(In reply to Mark Watson from comment #13)
> (In reply to Ryan Sleevi from comment #12)
> > (In reply to Mark Watson from comment #11)
> > > (In reply to Ryan Sleevi from comment #10)
> > > > 
> > > > AES-KW is useful, particularly with 'raw' keys, so I'm not suggesting
> > > > removing it. I definitely have serious reservations for suggesting it can be
> > > > safely/reliably used with respect to JWK in a 'non-canonical' form, since
> > > > JSON parsers are incredibly liberal in their checking, so I am more inclined
> > > > to suggest that the use of AES-KW (and/or AES-KW-PAD) should be forbidden
> > > > with JWK outright.
> > > 
> > > I don't think you've demonstrated any basis for such a change.
> > 
> > You're arguing for implementing application-specific padding schemes because
> > 1) Implementations don't support AES-KW-PAD
> > 2) You wish to use AES-KW with non-aligned data
> 
> Actually, I just want a way to wrap JWKs. I don't really mind what it is.
> But AES-KW has turned out to be the only option right now.
> 
> > 
> > I'm objecting, because the security properties of AES-KW are derived from:
> > 1) Assuming that the entire message is semantically the key (that is, NOT
> > structured data that describes the key)
> > 2) The key being the exact block size multiple
> 
> I'll read the document you referenced, but I'll note that there is nothing
> in the RFC that indicates the assumption (1).
> 
> Can you explain, though, why this problem would not apply also to AES-KW
> with padding (RFC5649) ? Or are you assuming that if we had that we would
> use a canonical JWK encoding ?

Yes. AES-KW-PAD shares the same assumption of "single key, all data is key data"

> 
> > 
> > Our fundamental disagreement is on whether or not AES-KW provides suitable
> > security guarantees under your proposed modifications.
> > 
> 
> I guess 'suitable' depends on the application and so isn't really for us to
> say - unless it's likely unsuitable for _all_ applications.

Yes, my assertion is that it's unsuitable for _all_ applications.

> 
> > * If not (as I assert), we should discourage or, arguably, forbid it -
> > because there's no *existing* impls supporting the combination proposed, so
> > there's no "legacy compat" issue.
> > * If so (as you assert), it's fine.
> > 
> > I think the burden of proof is on demonstrating its security, especially
> > under the proposed interpretations (eg: space padding), otherwise there's no
> > compelling reason to allow it. In the face of disagreement, the safe/good
> > option is to disallow it.
> 
> In favor of what ?

Using AES-GCM as a wrap alg?
Comment 15 Mark Watson 2014-02-07 02:54:18 UTC
(In reply to Ryan Sleevi from comment #14)
> (In reply to Mark Watson from comment #13)
> > (In reply to Ryan Sleevi from comment #12)
> > Can you explain, though, why this problem would not apply also to AES-KW
> > with padding (RFC5649) ? Or are you assuming that if we had that we would
> > use a canonical JWK encoding ?
> 
> Yes. AES-KW-PAD shares the same assumption of "single key, all data is key
> data"

Sorry, I asked two questions at once and it's unclear which you're answering yes to. You're comment on AES-KW-PAD being an acceptable solution assumes that we'd use a canonical JSON encoding, right ?
Comment 16 Mark Watson 2014-02-20 20:40:41 UTC
I discussed this issue with our security experts.

The contention is that the security assumptions underlying the design AES Key Wrap make it unsuitable for wrapping keys in a format which does not have a canonical representation for a given key. (For example JWK, where there can be arbitrary additional members which will be ignored on reception).

We don't agree with this contention.

From the introduction of http://csrc.nist.gov/groups/ST/toolkit/documents/kms/key-wrap.pdf (pay special attention to the first sentence, and then the second paragraph):

"This specification is intended to satisfy the NIST Key Wrap requirement to: Design a cryptographic algorithm called a Key Wrap that uses the Advanced Encryption Standard (AES) as a primitive to securely encrypt a plaintext key(s) with any associated integrity information and data, such that the combination could be longer than the width of the AES blocksize (128-bits). Each ciphertext bit should be a highly non-linear function of each plaintext bit, and (when unwrapping) each plaintext bit should be a highly non­ linear function of each ciphertext bit. It is sufficient to approximate an ideal pseudorandom permutation to the degree that exploitation of undesirable phenomena is as unlikely as guessing the AES engine key. This key wrap algorithm needs to provide ample security to protect keys in the context of a prudently designed key management architecture.

Throughout this document, any data being wrapped will be referred to as the key data. It makes no difference to the algorithm whether the data being wrapped is a key; in fact there is often good reason to include other data with the key, to wrap multiple keys together, or to wrap data that isn’t strictly a key. So, the term “key data” is used broadly to mean any data being wrapped, but particularly keys, since this is primarily a key wrap algorithm. The key used to do the wrapping will be referred to as the key encryption key (KEK). In this document a KEK can be any valid key supported by the AES codebook. That is, a KEK can be a 128-bit key, a 192-bit key, or a 256-bit key."

I also note that NIST SP800-38F states, in Section 3.1: 

"Although KW can be used in conjunction with any reversible padding scheme,.." suggesting that the design of the padding scheme does not, in fact, affect the security properties.

and 

"Similarly, KW, KWP, and TKW are each approved for the protection of general data, as well as cryptographic keys."

Also,

"KW, KWP, and TKW are each robust in the sense that each bit of output can be expected to depend in a nontrivial fashion on each bit of input, even when the length of the input data is greater than one block"

in contrast to, say, AES-GCM where each bit of ciphertext depends only on plaintext bits in the same or preceding blocks. One might naively expect that the above property of AES-KW makes attacks based on modification of the trailing end of the ciphertext (padding attacks) *more* difficult than with AES-GCM.

The security considerations of NIST SP800-38F do not make reference to any assumptions about the nature of the plaintext.

Finally, as far as we're aware, no practical attacks against AES-KW are known.

So, I would conclude from the above that there is no issue using AES-KW to wrap JSON data. Yes, the specification must state that it is an error to provide data that is not a multiple of 64 bits to AES-KW, but I see no problem with implementations that wrap JSON ensuring that the JSON object is a multiple of 8 characters - whilst still remaining a valid JSON string - by whatever means they choose, without needing any requirement in the specification to do so (of course, adding such a requirement would improve interoperability.
Comment 17 Mark Watson 2014-02-24 20:31:48 UTC
As discussed on 2/24/14 call, we do not see an issue here. The suggestion was to include a note to the effect that implementations may choose to use a JSON serialization which is a multiple of 8 bytes.
Comment 18 Mark Watson 2014-02-24 21:21:23 UTC
As per discussion on 2/24/14 call.

It's also suggested to add a note indicating that implementations may choose to generate JWK structures which are themselves a multiple of 8 bytes in length.
Comment 19 Alexey Proskuryakov 2014-02-26 17:37:55 UTC
A WebCrypto implementation can pad JWK with spaces for AES-KW, but the same padding can destroy the ability to wrap with RSA-OAEP, because you can run out of size limit. So, any padding should be conditional on which algorithm will be used for encryption in a later step of wrapping algorithm.

I think that it would be appropriate to have normative text. But even if it's simply a note, it should be:
1. Substantially more elaborate than suggested above.
2. Added as part of this bug (so it seems like the bug should remain open until the note is added).
Comment 20 Mark Watson 2014-03-05 22:43:15 UTC
Proposal from mailing list, to be added to wrapKey method description:

"Informative note: The key wrapping operations for some algorithms place constraints on the payload size. For example AES-KW requires the payload to be a multiple of 8 bytes in length and RSA-OAEP places a restriction on the length. For key formats that offer flexibility in serialization of a given key (for example JWK), implementations may choose to adapt the serialization to the constraints of the wrapping algorithm."
Comment 21 Mark Watson 2014-03-07 00:41:11 UTC
Changeset a3021bc66588 to add the note as proposed.