Subject: Re: [jose] WebCrypto feedback on key wrapping

From: Mike Jones <[email-masked]>
Date: Tue, 19 Mar 2013 03:28:42 +0000

I believe that the 2048 restriction was motivated by a NIST evaluation on acceptable key lengths in which the use of 1024 bit RSA keys has already been deprecated.  Eric Rescorla’s presentation to the working group several IETFs ago specifically recommended this, as well as the other key size restrictions in JWA.

At the time, the working group felt that requiring that people use keys of acceptable lengths for the current cryptographic client for new applications was a good thing - especially since JWS and JWE have no legacy applications to support.

-- Mike

From: Richard Barnes
Sent: ‎March‎ ‎18‎, ‎2013 ‎7‎:‎31‎ ‎PM
To: Mike Jones
CC: [email-masked]
Subject: Re: [jose] WebCrypto feedback on key wrapping

ISSUE-(n+1): Remove silly restriction on key sizes.  We're a formatting working group, not a crypto parameters working group.

--Richard

On Mon, Mar 18, 2013 at 8:02 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Given that we require RSA keys to be a minimum of 2048 bits in length, there’s no problem wrapping 768 bit keys with OAEP in practice.

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Monday, March 18, 2013 4:25 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] WebCrypto feedback on key wrapping

On today's call with the W3C WebCrypto working  group, I reported on the discussion of JOSE key wrapping at the last IETF.  I was asked to relay a few bits of feedback:

1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out of favor with some parts of the cryptographic community.  People prefer to be able to use AEAD algorithms for key wrapping, since they are perceived to be faster and offer a higher level of security than AES-KW. He gave the example that IEEE 802.1 uses AES CCM.

2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt wrapped key objects, then we would need something other than OAEP in order to carry arbitrary-length payloads.  I agreed, and suggested that something like RSA-KEM would be necessary.  Ryan Sleevi (Google) and Vijay observed that KEM is troublesome due to the lack of support by native crypto libraries.

It seems to me that these comments have impacts on JWE and JWS (pending ISSUE-2), as well as the wrapping discussion.  The former has more impact than the latter.

Point number 1 implies that we should offer AEAD for key wrapping in JWE as well as for wrapped keys.  It seems to me that the simplest approach to this would be to make the "alg" field contain an object that is semantically equivalent to an AlgorithmIdentifier in CMS/PKCS8.  For example, { name: "A128GCM", iv: "PCIGJe0DjunuM7s0" }.  This syntax, incidentally, is roughly the same form that algorithm identifiers have in the WebCrypto API.  Note that this type of key wrapping is supported in CMS by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo structure.

Point number 2 likely applies for some scenarios of JWE, especially if we adopt the McGrew approach.  For example, if using HMAC-SHA1 and AES with a 256-bit key, the total key length is 788 bits, which is too long to be encrypted with OAEP under a 1,024-bit RSA key.  I'm not sure how to resolve it.  The best idea I've got is to allow wrapped keys to nest, so that you can wrap a key inside of another wrapped key.

I will try to take these points into account in my forthcoming key wrapping draft, and I've filed two issues against JWE to track them.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 19 Mar 2013 09:44:45 -0400

I don't disagree that the minimum size is a good thing for implementors to
do.  I just don't think that that restriction is necessary in a formatting
document like JW*, since it has no impact on interoperability.  At most, it
should be RECOMMENDED in the security considerations.  It should not be a
MUST.

--Richard

On Mon, Mar 18, 2013 at 11:28 PM, Mike Jones <[email-masked]>wrote:

>  I believe that the 2048 restriction was motivated by a NIST evaluation
> on acceptable key lengths in which the use of 1024 bit RSA keys has already
> been deprecated.  Eric Rescorla’s presentation to the working group several
> IETFs ago specifically recommended this, as well as the other key size
> restrictions in JWA.
>
> At the time, the working group felt that requiring that people use keys of
> acceptable lengths for the current cryptographic client for new
> applications was a good thing - especially since JWS and JWE have no legacy
> applications to support.
>
> -- Mike
>
>  *From:* Richard Barnes
> *Sent:* March 18, 2013 7:31 PM
> *To:* Mike Jones
> *CC:* [email-masked]
> *Subject:* Re: [jose] WebCrypto feedback on key wrapping
>
> ISSUE-(n+1): Remove silly restriction on key sizes.  We're a formatting
> working group, not a crypto parameters working group.
>
>  --Richard
>
>
> On Mon, Mar 18, 2013 at 8:02 PM, Mike Jones <[email-masked]>wrote:
>
>>  Given that we require RSA keys to be a minimum of 2048 bits in length,
>> there’s no problem wrapping 768 bit keys with OAEP in practice.****
>>
>> ** **
>>
>>                                                                 -- Mike**
>> **
>>
>> ** **
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Richard Barnes
>> *Sent:* Monday, March 18, 2013 4:25 PM
>> *To:* [email-masked]
>> *Subject:* [jose] WebCrypto feedback on key wrapping****
>>
>> ** **
>>
>> On today's call with the W3C WebCrypto working  group, I reported on the
>> discussion of JOSE key wrapping at the last IETF.  I was asked to relay a
>> few bits of feedback:****
>>
>> ** **
>>
>> 1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out
>> of favor with some parts of the cryptographic community.  People prefer to
>> be able to use AEAD algorithms for key wrapping, since they are perceived
>> to be faster and offer a higher level of security than AES-KW. He gave the
>> example that IEEE 802.1 uses AES CCM.****
>>
>> ** **
>>
>> 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt
>> wrapped key objects, then we would need something other than OAEP in order
>> to carry arbitrary-length payloads.  I agreed, and suggested that something
>> like RSA-KEM would be necessary.  Ryan Sleevi (Google) and Vijay observed
>> that KEM is troublesome due to the lack of support by native crypto
>> libraries.****
>>
>> ** **
>>
>> It seems to me that these comments have impacts on JWE and JWS (pending
>> ISSUE-2), as well as the wrapping discussion.  The former has more impact
>> than the latter. ****
>>
>> ** **
>>
>> Point number 1 implies that we should offer AEAD for key wrapping in JWE
>> as well as for wrapped keys.  It seems to me that the simplest approach to
>> this would be to make the "alg" field contain an object that is
>> semantically equivalent to an AlgorithmIdentifier in CMS/PKCS8.  For
>> example, { name: "A128GCM", iv: "PCIGJe0DjunuM7s0" }.  This syntax,
>> incidentally, is roughly the same form that algorithm identifiers have in
>> the WebCrypto API.  Note that this type of key wrapping is supported in CMS
>> by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo
>> structure.  ****
>>
>> ** **
>>
>> Point number 2 likely applies for some scenarios of JWE, especially if we
>> adopt the McGrew approach.  For example, if using HMAC-SHA1 and AES with a
>> 256-bit key, the total key length is 788 bits, which is too long to be
>> encrypted with OAEP under a 1,024-bit RSA key.  I'm not sure how to resolve
>> it.  The best idea I've got is to allow wrapped keys to nest, so that you
>> can wrap a key inside of another wrapped key.****
>>
>> ** **
>>
>> I will try to take these points into account in my forthcoming key
>> wrapping draft, and I've filed two issues against JWE to track them.****
>>
>> ** **
>>
>> --Richard****
>>
>
>