Subject: [jose] Use of AES-HMAC algorithm

From: "Jim Schaad" <[email-masked]>
Date: Wed, 27 Mar 2013 15:20:42 -0700

<chair>
After spending time looking at and thinking about how to resolve this issue
since I was unable to do so at the last F2F meeting.  I have come up with
the following set of issues that might need to be addressed as part of
resolving this issue.

1.  Do we change from using KDC to having a double size key for the
algorithm?  I think that there is probably a consensus that this should be
done. 

2. Should IVs be prepended to the encrypted body as part of the encoding
steps?  If so then this change should be universal. 

Doing so would eliminate one field from all of the encoding formats which
should be considered a plus.
Doing so would force code writers to understand how large the IV is for all
algorithms as the IV would no longer be a separate item.

3. Should Authentication Tags be appended to the encrypted body as part of
the encoding steps?

Doing so would eliminate one field from all of the encoding formats which
should be considered a plus.
Doing so would force code writers to understand how large the IV is for all
algorithms as the IV would no longer be a separate item.
Doing so would force a re-organization for the multiple recipient case as
either all recipient specific data would need to be excluded from the
authentication step or all of the recipient data would need to be included
for by all recipients.
Changing how the recipient info is process is going to give a performance
benefit for sending encrypted items for multiple recipients.
The current strategy of a single IV and key pair with AES-GCM and different
authentication data needs to have CFRG look at it.  I am worried that it
might be a serious security flaw.

4. Should we reference the McGrew draft and provide text on how things are
changed or should we "copy" the draft into our text?

5.  If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping,
does this change how we think about any of the above questions?

Allowing for AES-GCM for key wrapping has a benefit for hardware situations
as only the encrypt and not the decrypt functions need to be placed in
hardware.  However allowing for this key wrapping give a problem as there is
no way to encode the three fields into the encrypted value unless with use
either a JSON structure in this location or we do use the single appended
binary output stream.  The first approach leads to an expansion of the field
by double base64 encoding which is highly undesirable.

Jim

---

From: Dick Hardt <[email-masked]>
Date: Wed, 27 Mar 2013 15:28:04 -0700

Hi Jim

Not being at the meeting, I don't have the background to understand what the issue was in order to interpret your email.

Having implementations that use AES-HMAC, I want to understand.

Any pointers so that I can understand would be greatly appreciated.

-- Dick

On Mar 27, 2013, at 3:20 PM, "Jim Schaad" <[email-masked]> wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Thu, 28 Mar 2013 00:21:19 +0000

Per your point 1, I don't think anyone was advocating doubling the key size.  The proposal in John's slides for issue #3 (http://trac.tools.ietf.org/wg/jose/trac/ticket/3) was to use a CMK that is the concatenation of the AES-CBC and HMAC-SHA-2 keys, as draft-mcgrew-aead-aes-hmac-sha2 does.  For instance, when using A128CBC with HS256, the key size would be 384 bits and when using A256CBC with HS512, the key size would be 768 bits.  This would multiply the current key sizes by 1.5, with the compensating benefit being the elimination of the use of the KDF.

Your point 2 wasn't part of issue #3.  This seems like an unnecessary change, particularly for GCM, where the IV is specified as a separate value from the ciphertext.

Your point 3 wasn't part of issue #3.  This seems like an unnecessary change, particularly for GCM, where the Authentication Tag is specified as a separate value from the ciphertext.

Per your point 4, after a conversation initiated by Joe Hildebrand and a call scheduled by Matt Miller, David McGrew has agreed refactor his draft so that the inputs and outputs are specified separately and independently from the RFC 5116 encoding of those values.  While RFC 5116 specifies a binary serialization for authenticated encryption algorithms, JWE specifies a textual serialization.  This refactoring would make it easy for JOSE to use the McGrew draft, since the computation would be specified separately from the serialization, should the working group choose to do so.

I suspect that once the refactoring is done, should the working group choose to use the McGrew algorithm, JWA could reference the appropriate sections of draft-mcgrew-aead-aes-hmac-sha2 and JWE could include an example computation for this algorithm, making it easy for developers to build.

Per your point 5, I think the term "key wrapping" is being used for two different things:  (1) Encrypting the ephemeral symmetric Content Master Key for a JWE and (2) encrypting a JWK or JWK Set containing symmetric and/or private key information and potentially other key attributes, enabling the encrypted JWK or JWK Set to be safely stored or transported.  It think it would clarify the discussions to keep these operations distinct.  I don't think anyone is proposing using AES-GCM or A128CBC+HS256 for (1), whereas they can already be used as part of (2) if the JWK is encrypted in a JWE, per Matt's draft.  Given the opinions voiced at the CFRG meeting that it's fine to use approved authenticated encryption algorithms to encrypt keys, I believe that there's already no problem with using these algorithms for (2).

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, March 27, 2013 3:21 PM
To: [email-masked]
Subject: [jose] Use of AES-HMAC algorithm

<chair>
After spending time looking at and thinking about how to resolve this issue since I was unable to do so at the last F2F meeting.  I have come up with the following set of issues that might need to be addressed as part of resolving this issue.

1.  Do we change from using KDC to having a double size key for the algorithm?  I think that there is probably a consensus that this should be done. 

2. Should IVs be prepended to the encrypted body as part of the encoding steps?  If so then this change should be universal. 

Doing so would eliminate one field from all of the encoding formats which should be considered a plus.
Doing so would force code writers to understand how large the IV is for all algorithms as the IV would no longer be a separate item.

3. Should Authentication Tags be appended to the encrypted body as part of the encoding steps?

Doing so would eliminate one field from all of the encoding formats which should be considered a plus.
Doing so would force code writers to understand how large the IV is for all algorithms as the IV would no longer be a separate item.
Doing so would force a re-organization for the multiple recipient case as either all recipient specific data would need to be excluded from the authentication step or all of the recipient data would need to be included for by all recipients.
Changing how the recipient info is process is going to give a performance benefit for sending encrypted items for multiple recipients.
The current strategy of a single IV and key pair with AES-GCM and different authentication data needs to have CFRG look at it.  I am worried that it might be a serious security flaw.

4. Should we reference the McGrew draft and provide text on how things are changed or should we "copy" the draft into our text?

5.  If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping, does this change how we think about any of the above questions?

Allowing for AES-GCM for key wrapping has a benefit for hardware situations as only the encrypt and not the decrypt functions need to be placed in hardware.  However allowing for this key wrapping give a problem as there is no way to encode the three fields into the encrypted value unless with use either a JSON structure in this location or we do use the single appended binary output stream.  The first approach leads to an expansion of the field by double base64 encoding which is highly undesirable.

Jim

---

From: Dick Hardt <[email-masked]>
Date: Wed, 27 Mar 2013 17:30:03 -0700

> Per your point 1, I don't think anyone was advocating doubling the key size.  The proposal in John's slides for issue #3 (http://trac.tools.ietf.org/wg/jose/trac/ticket/3) was to use a CMK that is…

Was this because people thought KDF was hard? I managed to implement it in JavaScript, can't be that hard! ;-) … or was there a security reason?

This is a breaking change to my implementation. 

FWIW: I cache the results of the KDF so that I only incur the calculation the first time I see a key.

---

From: Mike Jones <[email-masked]>
Date: Thu, 28 Mar 2013 00:39:01 +0000

I think the reason the working group is thinking about this algorithm is a combination of three things:

1.  Using the KDF could lead to interoperability problems.  Some early implementations have gotten this wrong.

2.  Apparently we're not using the Concat KDF for an approved use, as "approved" is defined by the NIST specs.  If we stop using it, this criticism would go away.

3.  Some have pushed back on us "inventing a new cryptographic algorithm".  While I believe that the composition of two establish algorithms - AES-CBC and HMAC SHA-2 is easily defensible, with David McGrew being the co-chair of the Crypto Forum Research Group (CFRG) - the group that IETF people go to when wanting to validate the use of crypto algorithms - if his algorithm is approved, using it would likely be considered to be above reproach, in terms of getting JWE through the IETF approval processes.

So it's really "spec approval" reasons - not security reasons that the change is being considered.

				-- Mike

P.S.  For what it's worth, you could distinguish the two algorithms by the key sizes if you wanted to run both algorithms side-by-side for a while.
 
-----Original Message-----
From: Dick Hardt [mailto:[email-masked]] 
Sent: Wednesday, March 27, 2013 5:30 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked]
Subject: Re: [jose] Use of AES-HMAC algorithm

> Per your point 1, I don't think anyone was advocating doubling the key size.  The proposal in John's slides for issue #3 (http://trac.tools.ietf.org/wg/jose/trac/ticket/3) was to use a CMK that is…

Was this because people thought KDF was hard? I managed to implement it in JavaScript, can't be that hard! ;-) ... or was there a security reason?

---

From: Dick Hardt <[email-masked]>
Date: Wed, 27 Mar 2013 18:05:54 -0700

> 1.  Using the KDF could lead to interoperability problems.  Some early implementations have gotten this wrong.

Were these improper implementations, or different interpretations? The first is a bug in the software, the second is a bug in the spec.

> 2.  Apparently we're not using the Concat KDF for an approved use, as "approved" is defined by the NIST specs.  If we stop using it, this criticism would go away.

Not relevant for me, but I understand the motivation.

> 3.  Some have pushed back on us "inventing a new cryptographic algorithm".  While I believe that the composition of two establish algorithms - AES-CBC and HMAC SHA-2 is easily defensible, with Davi…

What is David's algorithm?

> So it's really "spec approval" reasons - not security reasons that the change is being considered.

A smaller key is better than a larger key, but it is not that much larger. 

> P.S.  For what it's worth, you could distinguish the two algorithms by the key sizes if you wanted to run both algorithms side-by-side for a while.

Thanks for the suggestion. I can still change the implementation for the next couple weeks without impacting a third party. Would be useful to know where this will land so I can change or not.

P.S. thanks for the explanation Mike!

-- Dick

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 28 Mar 2013 13:49:02 +1100

Dick,

draft-mcgrew-aead-aes-cbc-hmac-sha2 "Authenticated Encryption with AES-CBC and HMAC-SHA" < http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2> is "David's algorithm".

Both draft-mcgrew-aead-aes-cbc-hmac-sha2 and "A128CBC+HS256" in JWA define a way to combine CBC and HMAC to get authenticated encryption. They make some different choices:

A. Concatenate CBC & HMAC keys vs use a KDF to derive CBC & HMAC keys;

B. 128+128 bit key sizes vs 128+256 bit keys size (for AES-128 & HMAC-256)

C. Authentication tag half the hash size vs the full hash size

D. Auth tag concatenated to ciphertext vs separate field

E. IV concatenated with ciphertext vs separate field

F. HMAC calculated over the raw ciphertext vs base64url-encoded ciphertext

Mike is right that the crypto choices (A, B, C) will be more acceptable coming from the Crypto Forum Research Group (CRFG) group in a spec specifically describing CBC+HMAC (with security considerations and rationales for its choices, plus test vectors etc), compared to a JOSE-specific definition that is a small part of a JWA doc.

D, E, & F are more to do with how the algorithms fit with crypto APIs. We will often have application code, JOSE library code, and crypto library code. The issues are which layers need to know which algorithm-specific details.

Crypto libraries have historically offered CBC and HMAC interfaces. Now they are starting to offer AEAD interfaces. The CBC+HMAC algorithm we put in JOSE should be able to work well with AEAD interfaces. Draft-mgrew will work as it fits a model for AEAD algorithms defined in RFC 5116 "An Interface and Algorithms for Authenticated Encryption". The current JOSE-specific alg will NOT fit AEAD interfaces well -- primarily because of difference F (that mixes app-layer base64url-encoding with a step that is internal to the AEAD algorithm).

The authentication tag (difference D) is a subtler issue. A tag is a core component of a bunch of AEAD algorithms so some AEAD APIs have explicit support for a tag field. However it is really an internal detail: either the decryption hands back plaintext or it fails. A crypto library's implementation of an AEAD alg that has a tag needs to distinguish the tag from the rest of the ciphertext -- but does the app-layer need to distinguish the two? Not really.

I understand (and hope) the JOSE consensus is to go with draft-mcgrew on points A, B, C, and F.

My opinion is that we should go with draft-mcgrew (and RFC5116) for D & E as well, but Mike (and others) disagree. It shouldn't affect the maths of the crypto, but it does affect APIs and the degree that the app layer can be (partially) relieved of the responsibility of dealing with some tough crypto issues (such as crypto-quality randomness, uniqueness of nonces etc).

--
James Manger

---

From: Dick Hardt <[email-masked]>
Date: Wed, 27 Mar 2013 20:32:19 -0700

Thanks for taking the time to explain James. Not being at the meetings makes it tough to track.

My summary of what you said is that there are two different ways that have been proposed to use AES-CBC and HMAC-SHA: the one currently in the spec, and "David's algorithm". 

FWIW as an implementer: none of the crypto libraries I have looked at are going to do D, E, & F for me; so I am doing them in my library and having them as separate fields vs yet-another-concatenation-algorithm is preferred. I can see why that would not be desirable if the format is then inconsistent with AEAD. Having said that, I'm coding in node.js, and even though it uses opensll that has AEAD, none of the AEAD interfaces are exposed currently in node.js, and I don't see that changing anytime soon => not sure AEAD is going to be incorporated with JWT libraries.

-- Dick

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 28 Mar 2013 15:40:40 +1100

I haven’t been at any of the meeting either! It is hard to track.

Java added AEAD support in v7 (eg javax.crypto.cipher#updateAAD).
OpenSSL has added AEAD support.
I think OpenSSL AEAD support has filtered into Ruby.
Apparently it hasn't filtered into node.js yet.
Microsoft Crypto Next Generation (Cng) has added AEAD support.
Go supports AE-without-the-AD, as does NaCl.

So I think JOSE will live long enough for explicit AEAD support in crypto libraries to be the norm.

--
James Manger

> Sent: Thursday, 28 March 2013 2:32 PM
> To: Manger, James H
> Cc: Mike Jones; Jim Schaad; [email-masked]
> My summary of what you said is that there are two different ways that
> have been proposed to use AES-CBC and HMAC-SHA: the one currently in
> the spec, and "David's algorithm".
> 
> FWIW as an implementer: none of the crypto libraries I have looked at
> are going to do D, E, & F for me; so I am doing them in my library and
> having them as separate fields vs yet-another-concatenation-algorithm
> is preferred. I can see why that would not be desirable if the format
> is then inconsistent with AEAD. Having said that, I'm coding in
> node.js, and even though it uses opensll that has AEAD, none of the
> AEAD interfaces are exposed currently in node.js, and I don't see that
> changing anytime soon => not sure AEAD is going to be incorporated with
> JWT libraries.
> 
> -- Dick
> 
> > draft-mcgrew-aead-aes-cbc-hmac-sha2 "Authenticated Encryption with
> AES-CBC and HMAC-SHA" < http://tools.ietf.org/html/draft-mcgrew-aead-
> aes-cbc-hmac-sha2> is "David's algorithm".
> >
> >
> > Both draft-mcgrew-aead-aes-cbc-hmac-sha2 and "A128CBC+HS256" in JWA
> define a way to combine CBC and HMAC to get authenticated encryption.
> They make some different choices:
> >
> > Mike is right that the crypto choices (A, B, C) will be more
> acceptable coming from the Crypto Forum Research Group (CRFG) group in
> a spec specifically describing CBC+HMAC (with security considerations
> and rationales for its choices, plus test vectors etc), compared to a
> JOSE-specific definition that is a small part of a JWA doc.
> >
> > D, E, & F are more to do with how the algorithms fit with crypto
> APIs. We will often have application code, JOSE library code, and
> crypto library code. The issues are which layers need to know which
> algorithm-specific details.
> >
> > Crypto libraries have historically offered CBC and HMAC interfaces.
> Now they are starting to offer AEAD interfaces. The CBC+HMAC algorithm
> we put in JOSE should be able to work well with AEAD interfaces. Draft-
> mgrew will work as it fits a model for AEAD algorithms defined in RFC
> 5116 "An Interface and Algorithms for Authenticated Encryption". The
> current JOSE-specific alg will NOT fit AEAD interfaces well --
> primarily because of difference F (that mixes app-layer base64url-
> encoding with a step that is internal to the AEAD algorithm).
> >
> > The authentication tag (difference D) is a subtler issue. A tag is a
> core component of a bunch of AEAD algorithms so some AEAD APIs have
> explicit support for a tag field. However it is really an internal
> detail: either the decryption hands back plaintext or it fails. A
> crypto library's implementation of an AEAD alg that has a tag needs to
> distinguish the tag from the rest of the ciphertext -- but does the
> app-layer need to distinguish the two? Not really.
> >
> >
> > My opinion is that we should go with draft-mcgrew (and RFC5116) for D
> & E as well, but Mike (and others) disagree. It shouldn't affect the
> maths of the crypto, but it does affect APIs and the degree that the
> app layer can be (partially) relieved of the responsibility of dealing
> with some tough crypto issues (such as crypto-quality randomness,
> uniqueness of nonces etc).
> >
> > --
> > James Manger
> >

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 28 Mar 2013 19:13:48 -0700

Sorry for the delayed response - my mail server was not delivering mail
since I updated a certificate.

> From: Mike Jones [mailto:[email-masked]]
> Sent: Wednesday, March 27, 2013 5:21 PM
> To: Jim Schaad; [email-masked]
> Subject: RE: [jose] Use of AES-HMAC algorithm
> 
> Per your point 1, I don't think anyone was advocating doubling the key
size.  The
> proposal in John's slides for issue #3
> (http://trac.tools.ietf.org/wg/jose/trac/ticket/3) was to use a CMK that
is the
> concatenation of the AES-CBC and HMAC-SHA-2 keys, as draft-mcgrew-aead-
> aes-hmac-sha2 does.  For instance, when using A128CBC with HS256, the key
> size would be 384 bits and when using A256CBC with HS512, the key size
would
> be 768 bits.  This would multiply the current key sizes by 1.5, with the
> compensating benefit being the elimination of the use of the KDF.

Doubling was indeed a poor choice of words - but I think you are
understanding things.  We are going to go from a 256 bit key to a 768 bit
key - that is actually a tripling  of size for the A256CBC + HS512.  

> 
> Your point 2 wasn't part of issue #3.  This seems like an unnecessary
change,
> particularly for GCM, where the IV is specified as a separate value from
the
> ciphertext.
> 
> Your point 3 wasn't part of issue #3.  This seems like an unnecessary
change,
> particularly for GCM, where the Authentication Tag is specified as a
separate
> value from the ciphertext.
> 
> Per your point 4, after a conversation initiated by Joe Hildebrand and a
call
> scheduled by Matt Miller, David McGrew has agreed refactor his draft so
that
> the inputs and outputs are specified separately and independently from the
RFC
> 5116 encoding of those values.  While RFC 5116 specifies a binary
serialization
> for authenticated encryption algorithms, JWE specifies a textual
serialization.
> This refactoring would make it easy for JOSE to use the McGrew draft,
since
> the computation would be specified separately from the serialization,
should
> the working group choose to do so.
> 
> I suspect that once the refactoring is done, should the working group
choose to
> use the McGrew algorithm, JWA could reference the appropriate sections of
> draft-mcgrew-aead-aes-hmac-sha2 and JWE could include an example
> computation for this algorithm, making it easy for developers to build.
> 
> Per your point 5, I think the term "key wrapping" is being used for two
different
> things:  (1) Encrypting the ephemeral symmetric Content Master Key for a
JWE
> and (2) encrypting a JWK or JWK Set containing symmetric and/or private
key
> information and potentially other key attributes, enabling the encrypted
JWK or
> JWK Set to be safely stored or transported.  It think it would clarify the
> discussions to keep these operations distinct.  I don't think anyone is
proposing
> using AES-GCM or A128CBC+HS256 for (1), whereas they can already be used
> as part of (2) if the JWK is encrypted in a JWE, per Matt's draft.  Given
the
> opinions voiced at the CFRG meeting that it's fine to use approved
> authenticated encryption algorithms to encrypt keys, I believe that
there's
> already no problem with using these algorithms for (2).

I was actually looking at the case of wrapping the CMK and not wrapping
content when I wrote point 5.

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jim
> Schaad
the
> following set of issues that might need to be addressed as part of
resolving this
> issue.
algorithm?
> I think that there is probably a consensus that this should be done.
> 
the
> encoding steps?
either
> all recipient specific data would need to be excluded from the
authentication
> step or all of the recipient data would need to be included for by all
recipients.
> authentication data needs to have CFRG look at it.  I am worried that it
might
> be a serious security flaw.
> 
binary
> output stream.  The first approach leads to an expansion of the field by
double
> base64 encoding which is highly undesirable.
> 
> Jim
> 
>