Subject: [jose] Comments on json-web-algorithms-08 encryption

From: "Peck, Michael A" <[email-masked]>
Date: Mon, 4 Mar 2013 04:00:02 +0000

Hi,

I have comments on how encryption is performed as defined in draft-ietf-jose-json-web-algorithms-08 .

Section 4.2:
The content encryption algorithms defined in Section 4.2 are all AEAD algorithms.  I would suggest using the RFC 5116 authenticated encryption interface for all of these (AEAD_AES_128_GCM and AEAD_AES_256_GCM as defined in that RFC, and the AES-CBC+HMAC algorithms defined in draft-mcgrew-aead-aes-cbc-hmac-sha2).  This would provide an opportunity for consistency across IETF protocols and the potential for easier re-use of crypto library code that properly handles the details of authenticated encryption.  I see there was discussion along these lines on the mailing list last November but did not see any outcome.

Section 4.6:
The "Direct Encryption with a Shared Symmetric Key" option seems to not be safe to use with AES-GCM because of the risk of re-using the same key and IV pair.  One potential way to resolve this may be for the sender to provide a nonce (equal to the size of the shared symmetric key), and the sender and recipient combine the nonce with their shared symmetric key to form the CMK.  For example, based on RFC 5869 Section 2.2, CMK = HMAC-SHA-256(HMAC key = nonce, HMAC message input = shared symmetric key).

Section 4.8 - A128CBC+HS256 and A256CBC+HS512:
I don't understand why AES-128 is combined with HMAC-SHA-256 with a full 256-bit authentication tag, and similarly why AES-256 is combined with HMAC-SHA-512 with a full 512-bit authentication tag.  Section 4.8 states that the integrity check provides "matching strength" but in these cases the integrity check provides twice the strength of the encryption.
Instead, how about truncating the HMAC output in half?  Then the HMAC key can also be truncated in half, and the CMK will only need to be the length of the encryption key leading to additional compactness (and less chance of confusion about the provided security level).
draft-mcgrew-aead-aes-cbc-hmac-sha2 already truncates the authentication tag.  draft-mcgrew-aead-aes-cbc-hmac-sha2 expects to be provided a key that is of the form ENC_KEY || MAC_KEY, but the JWE CMK could still be used in a way that is compatible: just have JWE take its CMK and derive ENC_KEY || MAC_KEY before calling the aead-aes-cbc-hmac-sha2 interface.

Thanks,
Mike

---

From: Richard Barnes <[email-masked]>
Date: Mon, 4 Mar 2013 16:29:00 -0500

These are excellent comments.  Thanks, Mike.  A couple of comments inline.

Section 4.2:****
>
> The content encryption algorithms defined in Section 4.2 are all AEAD
> algorithms.  I would suggest using the RFC 5116 authenticated encryption
> interface for all of these (AEAD_AES_128_GCM and AEAD_AES_256_GCM as
> defined in that RFC, and the AES-CBC+HMAC algorithms defined in
> draft-mcgrew-aead-aes-cbc-hmac-sha2).  This would provide an opportunity
> for consistency across IETF protocols and the potential for easier re-use
> of crypto library code that properly handles the details of authenticated
> encryption.  I see there was discussion along these lines on the mailing
> list last November but did not see any outcome.
>

This should definitely be done, for the consistency reasons noted.  If we
do this, and use draft-mcgrew-aead-aes-cbc-hmac-sha2 as the general AEAD
framework, then we can get rid of the separate ICV field in JWE.

Section 4.6:****
>
> The “Direct Encryption with a Shared Symmetric Key” option seems to not be
> safe to use with AES-GCM because of the risk of re-using the same key and
> IV pair.  One potential way to resolve this may be for the sender to
> provide a nonce (equal to the size of the shared symmetric key), and the
> sender and recipient combine the nonce with their shared symmetric key to
> form the CMK.  For example, based on RFC 5869 Section 2.2, CMK =
> HMAC-SHA-256(HMAC key = nonce, HMAC message input = shared symmetric key).
>

When direct encryption is done with GCM (alg=dir, enc=A128GCM), the key is
re-used, but a new IV is generated for every message.  From Section 4.9: "Use
of an initialization vector of size 96 bits is REQUIRED with this algorithm"
 That helps to mitigate the problem of key/IV re-use.  But I agree that
this is fragile; if IVs repeat, everything breaks.  That seems like yet
another argument for just disallowing direct encryption and requiring a
random CMK.

> **
>
> Section 4.8 - A128CBC+HS256 and A256CBC+HS512:****
>
> I don’t understand why AES-128 is combined with HMAC-SHA-256 with a full
> 256-bit authentication tag, and similarly why AES-256 is combined with
> HMAC-SHA-512 with a full 512-bit authentication tag.  Section 4.8 states
> that the integrity check provides “matching strength” but in these cases
> the integrity check provides twice the strength of the encryption.  ****
>
> Instead, how about truncating the HMAC output in half?  Then the HMAC key
> can also be truncated in half, and the CMK will only need to be the length
> of the encryption key leading to additional compactness (and less chance of
> confusion about the provided security level).  ****
>
> draft-mcgrew-aead-aes-cbc-hmac-sha2 already truncates the authentication
> tag.  draft-mcgrew-aead-aes-cbc-hmac-sha2 expects to be provided a key that
> is of the form ENC_KEY || MAC_KEY, but the JWE CMK could still be used in a
> way that is compatible: just have JWE take its CMK and derive ENC_KEY ||
> MAC_KEY before calling the aead-aes-cbc-hmac-sha2 interface
>

Or we could just have CMK == ENC_KEY || MAC_KEY.  That would avoid the
issues with FIPS noted in Issue 3.
<http://tools.ietf.org/wg/jose/trac/ticket/3>

--Richard

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 4 Mar 2013 21:02:48 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peck, Michael A
Sent: Sunday, March 03, 2013 11:00 PM
To: [email-masked]
Subject: [jose] Comments on json-web-algorithms-08 encryption

Hi,

I have comments on how encryption is performed as defined in
draft-ietf-jose-json-web-algorithms-08 .

Section 4.2:

The content encryption algorithms defined in Section 4.2 are all AEAD
algorithms.  I would suggest using the RFC 5116 authenticated encryption
interface for all of these (AEAD_AES_128_GCM and AEAD_AES_256_GCM as defined
in that RFC, and the AES-CBC+HMAC algorithms defined in
draft-mcgrew-aead-aes-cbc-hmac-sha2).  This would provide an opportunity for
consistency across IETF protocols and the potential for easier re-use of
crypto library code that properly handles the details of authenticated
encryption.  I see there was discussion along these lines on the mailing
list last November but did not see any outcome.

[JLS] I would note that S/MIME AuthEnvelopedData [RFC 5083] does not use
this interface - so you will be consistent with somebody either way.

Section 4.6:

The "Direct Encryption with a Shared Symmetric Key" option seems to not be
safe to use with AES-GCM because of the risk of re-using the same key and IV
pair.  One potential way to resolve this may be for the sender to provide a
nonce (equal to the size of the shared symmetric key), and the sender and
recipient combine the nonce with their shared symmetric key to form the CMK.
For example, based on RFC 5869 Section 2.2, CMK = HMAC-SHA-256(HMAC key =
nonce, HMAC message input = shared symmetric key).

I don't understand why AES-128 is combined with HMAC-SHA-256 with a full
256-bit authentication tag, and similarly why AES-256 is combined with
HMAC-SHA-512 with a full 512-bit authentication tag.  Section 4.8 states
that the integrity check provides "matching strength" but in these cases the
integrity check provides twice the strength of the encryption.  

Instead, how about truncating the HMAC output in half?  Then the HMAC key
can also be truncated in half, and the CMK will only need to be the length
of the encryption key leading to additional compactness (and less chance of
confusion about the provided security level).  

MAC_KEY before calling the aead-aes-cbc-hmac-sha2 interface.

Thanks,

Mike