Subject: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key

From: Michael Jones <[email-masked]>
Date: Fri, 9 Nov 2012 10:06:22 -0800

Some working group members, including Axel, James, Matt, and
Richard have expressed dissatisfaction with the use of the Concat KDF to
generate the CEK and CIK when AES CBC is the block encryption algorithm.  Reasons stated are implementation complexity
and possible issues with following the letter of the law of the NIST spec.  Axel and Richard had both written suggesting an
alternative – let the CMK be simply the concatenation of the CEK and the CIK
values.  This is the same approach used
in draft-mcgrew-aead-aes-cbc-hmac-sha2.

I and others had argued against this for size
reasons.  For A128CBC+HS256 this would
increase the CMK size from 256 bits to 384 bits and for A256CBC+HS512 this
would increase the CMK size from 512 bits to 768 bits.  In the first case, after base64url encoding, one
would expect the extra 128 bits to require about an extra 21 bytes in the JWE.  The interesting fact though, is that when an
RSA algorithm is used to encrypt the CMK, the output size is same as the RSA key
size – in our case, a minimum of 2048 bits. 
Thus, for any combination of “alg”:”RSA1_5” or “RSA-OAEP” and “enc”:”A128CBC+HS256”
or “A256CBC+HS512” there is no actual
size difference in the JWE.  (However
when “alg”:”A128KW” or “A256KW” are used, there would be a size increase of
about 21 or 43 bytes, respectively.)

So I’d like to explicitly ask the working group.  Do you want us to:

(1) Use the concatenation of random CEK and CIK values as
the CMK for AES CBC, resulting in a longer CMK?

(2) Continue to use a KDF to generate the CEK and CIK
from a shorter CMK?

                                                            Thanks all,

                                                            --
Mike

P.S.  A KDF will
still be required for ECDH-ES key agreement. 
I’ll address James’ concerns about our use of Concat in a separate note.

---

From: Axel Nennker <[email-masked]>
Date: Fri, 9 Nov 2012 19:48:32 +0100

My suggestion did not change the CMK size. I think it can stay as is.
I think that the concat-kdf is hard to  implement in Firefox/NSS in
Javascript if more than one iteration is needed. For the examples in the
spec there is no iteration and so there  is no problem.
There is a problem when NIST compliance is really required because CEK and
CIK should be computed in one go.
I could live with a NIST-like concat-KDF. I think openid connect even does
not need the  optional sender/receiver-ids.
Most important is the randomness of the CMK.

I don't understand the choices you provided. I think the CMK can stay a
defined.

// cmk size matters. more bytes give better cik and cek.
// cmk size does not change encodedEncryptedKeySegment if alg = RSA1_5 or
RSA-OAEP
cmk = generateRandomKey(size, enc);
// cik and cek have as many bytes as required by enc
(cik,cek) = some-kdf(cmk, otherInfoInput);

Axel

2012/11/9 Michael Jones <[email-masked]>

>  Some working group members, including Axel, James, Matt, and Richard
> have expressed dissatisfaction with the use of the Concat KDF to generate
> the CEK and CIK when AES CBC is the block encryption algorithm.  Reasons
> stated are implementation complexity and possible issues with following the
> letter of the law of the NIST spec.  Axel and Richard had both written
> suggesting an alternative – let the CMK be simply the concatenation of the
> CEK and the CIK values.  This is the same approach used in
> draft-mcgrew-aead-aes-cbc-hmac-sha2.******
>
> ** **
>
> I and others had argued against this for size reasons.  For A128CBC+HS256
> this would increase the CMK size from 256 bits to 384 bits and for
> A256CBC+HS512 this would increase the CMK size from 512 bits to 768 bits.
> In the first case, after base64url encoding, one would expect the extra
> 128 bits to require about an extra 21 bytes in the JWE.  The interesting
> fact though, is that when an RSA algorithm is used to encrypt the CMK, the
> output size is same as the RSA key size – in our case, a minimum of 2048
> bits.  Thus, for any combination of “alg”:”RSA1_5” or “RSA-OAEP” and
> “enc”:”A128CBC+HS256” or “A256CBC+HS512” *there is no actual size
> difference in the JWE*.  (However when “alg”:”A128KW” or “A256KW” are
> used, there would be a size increase of about 21 or 43 bytes, respectively.)
> ****
>
> ** **
>
> So I’d like to explicitly ask the working group.  Do you want us to:****
>
> ** **
>
> (1) Use the concatenation of random CEK and CIK values as the CMK for AES
> CBC, resulting in a longer CMK?****
>
> (2) Continue to use a KDF to generate the CEK and CIK from a shorter CMK?*
> ***
>
> ** **
>
>                                                             Thanks all,***
> *
>
>                                                             -- Mike****
>
> ** **
>
> P.S.  A KDF will still be required for ECDH-ES key agreement.  I’ll
> address James’ concerns about our use of Concat in a separate note.****
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: Michael Jones <[email-masked]>
Date: Fri, 9 Nov 2012 10:55:45 -0800

So it sounds to me like you're in favor of (2) Continue to use a KDF to generate the CEK and CIK from a shorter CMK.                                                             --Mike
 Date: Fri, 9 Nov 2012 19:48:32 +0100
From: [email-masked]
To: [email-masked]
CC: [email-masked]
Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key

My suggestion did not change the CMK size. I think it can stay as is.
I think that the concat-kdf is hard to  implement in Firefox/NSS in Javascript if more than one iteration is needed. For the examples in the spec there is no iteration and so there  is no problem.

There is a problem when NIST compliance is really required because CEK and CIK should be computed in one go.
I could live with a NIST-like concat-KDF. I think openid connect even does not need the  optional sender/receiver-ids.

I don't understand the choices you provided. I think the CMK can stay a defined.

// cmk size matters. more bytes give better cik and cek. 
// cmk size does not change encodedEncryptedKeySegment if alg = RSA1_5 or RSA-OAEP

Axel

                                                            Thanks all,

                                                            --
Mike

P.S.  A KDF will

jose mailing list

[email-masked]

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 12 Nov 2012 09:23:37 +1100

> (1) Use the concatenation of random CEK and CIK values as the CMK for AES CBC, resulting in a longer CMK?
> (2) Continue to use a KDF to generate the CEK and CIK from a shorter CMK?

1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2

--
James Manger

---

From: John Bradley <[email-masked]>
Date: Sun, 11 Nov 2012 21:27:16 -0300

I think that is largely the effect of making the proposed change.  The remaining question if we do it is if we want to take a dependency on draft-mcgrew-aead-aes-cbc-hmac-sha2 or incorporate it.

If it is a ID taking a dependency on it is problematic proceduraly.

I am personally in favour of sending the concatenation of the two values rather than use a KDF.  I think it will reduce interoperability issues.

What we call it needs to be determined.

John B.

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 12 Nov 2012 12:21:08 +1100

> I think that is largely the effect of making the proposed change.  The
> remaining question if we do it is if we want to take a dependency on
> draft-mcgrew-aead-aes-cbc-hmac-sha2 or incorporate it.
> 

What is the procedural problem? Is this a timing thing -- you don't want a JOSE draft to have to wait for the draft-mcgrew-aead-aes-cbc-hmac-sha2 draft?

--
James Manger

---

From: Michael Jones <[email-masked]>
Date: Sun, 11 Nov 2012 17:30:54 -0800

Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1).  For instance, as was discussed after David's presentation at IETF 84, draft-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of AEAD algorithms such as AES GCM, which have two inputs (plaintext, "additional authenticated data"), and two outputs (ciphertext, "authentication tag").  Instead, it adds a step combining the ciphertext and "authentication tag" outputs. If you read the draft, implementation of draft-mcgrew-aead-aes-cbc-hmac-sha2 has a lot more steps than what we have for A128CBC+HS256 and A256CBC+HS512.  It requires generating and adding specific padding bytes.  It prefixes the ciphertext with the IV.  It includes the length of the "additional authenticated data" in the MAC calculation.  It combines the two outputs into one.  For decryption, likewise, the two outputs must be split apart, the IV must be split apart, etc. All of these are steps that implementations could get wrong, resulting in interoperability problems.  By keeping all the parameters separate, our current A128CBC+HS256 and A256CBC+HS512 algorithms eliminate those steps. I'm sorry for the apparent confusion between (1) and draft-mcgrew-aead-aes-cbc-hmac-sha2.  While they both explicitly represent the CMK and CEK, and use the same underlying crypto operations, the details differ in ways that are likely to matter to implementers.  If there was a version of draft-mcgrew-aead-aes-cbc-hmac-sha2 that kept all the inputs and outputs separate, I agree that it would be a reasonable candidate for JOSE to consider.  But unlike AES GCM, that's not what it does. -- Mike
 > From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Mon, 12 Nov 2012 09:23:37 +1100
> Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key
>

---

From: John Bradley <[email-masked]>
Date: Sun, 11 Nov 2012 22:54:00 -0300

Sorry I was only thinking of the KDF issue not the other differences.   You far correct there are still non trivia differences between the two.

The two are closer but not the same.  

I caught the flue on my way home from IETF and probably need to get off the cold medication before answering email.

John
On 2012-11-11, at 10:30 PM, Michael Jones <[email-masked]> wrote:

> Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1).  For instance, as was discussed after David's presentation at IETF 84, draft-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of AEAD algorithms such as AES GCM, which have two inputs (plaintext, "additional authenticated data"), and two outputs (ciphertext, "authentication tag").  Instead, it adds a step combining the ciphertext and "authentication tag" outputs.
>  
> If you read the draft, implementation of draft-mcgrew-aead-aes-cbc-hmac-sha2 has a lot more steps than what we have for A128CBC+HS256 and A256CBC+HS512.  It requires generating and adding specific padding bytes.  It prefixes the ciphertext with the IV.  It includes the length of the "additional authenticated data" in the MAC calculation.  It combines the two outputs into one.  For decryption, likewise, the two outputs must be split apart, the IV must be split apart, etc.
>  
> All of these are steps that implementations could get wrong, resulting in interoperability problems.  By keeping all the parameters separate, our current A128CBC+HS256 and A256CBC+HS512 algorithms eliminate those steps.
>  
> I'm sorry for the apparent confusion between (1) and draft-mcgrew-aead-aes-cbc-hmac-sha2.  While they both explicitly represent the CMK and CEK, and use the same underlying crypto operations, the details differ in ways that are likely to matter to implementers.  If there was a version of draft-mcgrew-aead-aes-cbc-hmac-sha2 that kept all the inputs and outputs separate, I agree that it would be a reasonable candidate for JOSE to consider.  But unlike AES GCM, that's not what it does.
>  
> -- Mike
>

---

From: John Bradley <[email-masked]>
Date: Sun, 11 Nov 2012 22:58:34 -0300

Yes without draft-mcgrew-aead-aes-cbc-hmac-sha2 having a clear path to RFC I would not want to have a dependency on it.

Mike correctly points out that there are other outstanding differences between the two as well.

John

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 12 Nov 2012 14:06:46 +1100

> Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1).

Then change my vote to:

(1b) Use draft-mcgrew-aead-aes-cbc-hmac-sha2

I know draft-mcgrew-aead-aes-cbc-hmac-sha2 is not quite the same as A128CBC+HS256-without-a-KDF. There are a handful of “distinctions-without-a-difference” and some differences that are subtle but important where draft-mcgrew is better.

> It requires generating and adding specific padding bytes.

They both add identical padding. draft-mcgrew spells it out; A128CBC+HS256 just refers to PKCS #5 padding (without much of a reference).

> It prefixes the ciphertext with the IV.

Good design. But if JOSE insists on separate B64-encoded fields it is trivial to convert.

> It includes the length of the "additional authenticated data" in the MAC calculation.

Great design. A128CBC+HS256, in contrast, relies on an extra B64-encoding step to safely distinguish “additional data” and “ciphertext”. A128CBC+HS256 has to MAC up to 33% more bytes than draft-mcgrew (when the plaintext size dominates).

While general-purpose crypto libraries only implement the AES & HMAC components but not the AEAD combination (and A128CBC+HS256 is only applied to small messages), it doesn’t matter much. However, once crypto libraries offer AEAD APIs it does. A128CBC+HS256 requires the “inside” of the crypto API to have the raw and B64 data but only one form will be passed across the API. That locks in duplicated effort and overhead so much so that I expect general purpose crypto libraries will support draft-mcgrew but not A128CBC+HS256.

> It combines the two outputs into one.

Again good design, but trivial to separate if desired.

Both JWA and draft-mcgrew refer to RFC 5116 “An Interface and Algorithms for Authenticated Encryption”. JOSE should follow the pattern specified in that RFC, which draft-mcgrew does.

--
James Manger

From: Michael Jones [mailto:[email-masked]]
Sent: Monday, 12 November 2012 12:31 PM
To: Manger, James H; [email-masked]
Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key

-- Mike

> From: [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Michael Jones <[email-masked]>
Date: Sun, 11 Nov 2012 19:15:17 -0800

I'm not sure why you're saying that combing fields with distinct meanings is good design.  It just means extra, unnecessary steps.  The pattern used by AES GCM, which keeps fields with distinct meanings separate, seems more general and cleaner to me. I think this may be one of those points where we may just have to agree to disagree, because it doesn't seem that that either of us is convincing the other. ;-)
Cheers,-- Mike From: [email-masked]
To: [email-masked]; [email-masked]
Date: Mon, 12 Nov 2012 14:06:46 +1100
Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key

> Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1).  Then change my vote to: (1b) Use draft-mcgrew-aead-aes-cbc-hmac-sha2 I know draft-mcgrew-aead-aes-cbc-hmac-sha2 is not quite the same as A128CBC+HS256-without-a-KDF. There are a handful of “distinctions-without-a-difference” and some differences that are subtle but important where draft-mcgrew is better. > It requires generating and adding specific padding bytes. They both add identical padding. draft-mcgrew spells it out; A128CBC+HS256 just refers to PKCS #5 padding (without much of a reference). > It prefixes the ciphertext with the IV. Good design. But if JOSE insists on separate B64-encoded fields it is trivial to convert. > It includes the length of the "additional authenticated data" in the MAC calculation. Great design. A128CBC+HS256, in contrast, relies on an extra B64-encoding step to safely distinguish “additional data” and “ciphertext”. A128CBC+HS256 has to MAC up to 33% more bytes than draft-mcgrew (when the plaintext size dominates). While general-purpose crypto libraries only implement the AES & HMAC components but not the AEAD combination (and A128CBC+HS256 is only applied to small messages), it doesn’t matter much. However, once crypto libraries offer AEAD APIs it does. A128CBC+HS256 requires the “inside” of the crypto API to have the raw and B64 data but only one form will be passed across the API. That locks in duplicated effort and overhead so much so that I expect general purpose crypto libraries will support draft-mcgrew but not A128CBC+HS256. > It combines the two outputs into one. Again good design, but trivial to separate if desired.  Both JWA and draft-mcgrew refer to RFC 5116 “An Interface and Algorithms for Authenticated Encryption”. JOSE should follow the pattern specified in that RFC, which draft-mcgrew does. --James Manger From: Michael Jones [mailto:[email-masked]] 
Sent: Monday, 12 November 2012 12:31 PM
To: Manger, James H; [email-masked]
Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1).  For instance, as was discussed after David's presentation at IETF 84, draft-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of AEAD algorithms such as AES GCM, which have two inputs (plaintext, "additional authenticated data"), and two outputs (ciphertext, "authentication tag").  Instead, it adds a step combining the ciphertext and "authentication tag" outputs.

 
 
-- Mike

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Nov 2012 13:13:38 +0000

FWIW, I'd say asking David and/or CFRG about stuff like this
ought be useful. Features that are a "don't care" from the
jose WG/protocol perspective might well be important either for
security reasons or because of re-use in other protocols.

S.

On 11/12/2012 03:15 AM, Michael Jones wrote:
>> Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1).  Then change my vote to: (1b) Use draft-mcgrew-aead-aes-cbc-hmac-sha2 I know draft-mcgrew-aead-aes-cbc-hmac-sha2 is not quite the same as A128CBC+HS256-without-a-KDF. There are a handful of “distinctions-without-a-difference” and some differences that are subtle but important where draft-mcgrew is better. > It requires generating and adding specific padding bytes. They both add identical padding. draft-mcgrew spells it out; A128CBC+HS256 just refers to PKCS #5 padding (without much of a reference). > It prefixes the ciphertext with the IV. Good design. But if JOSE insists on separate B64-encoded fields it is trivial to convert. > It includes the length of the "additional authenticated data" in the MAC calculation. Great design. A128CBC+HS256, in contrast, relies on an extra B64-encoding step to safely distinguish “additional data” and “ciphertext”. A128CBC+HS256 has to MAC up to 33% more bytes than dra
 ft-mcgrew
 (when the plaintext size dominates). While general-purpose crypto libraries only implement the AES & HMAC components but not the AEAD combination (and A128CBC+HS256 is only applied to small messages), it doesn’t matter much. However, once crypto libraries offer AEAD APIs it does. A128CBC+HS256 requires the “inside” of the crypto API to have the raw and B64 data but only one form will be passed across the API. That locks in duplicated effort and overhead so much so that I expect general purpose crypto libraries will support draft-mcgrew but not A128CBC+HS256. > It combines the two outputs into one. Again good design, but trivial to separate if desired.  Both JWA and draft-mcgrew refer to RFC 5116 “An Interface and Algorithms for Authenticated Encryption”. JOSE should follow the pattern specified in that RFC, which draft-mcgrew does. --James Manger From: Michael Jones [mailto:[email-masked]]

---

From: Mike Jones <[email-masked]>
Date: Mon, 12 Nov 2012 01:28:44 +0000

-- Mike