Subject: [jose] Discussion Topic - Lets kill all non AEAD algorithms

From: "Jim Schaad" <[email-masked]>
Date: Sun, 3 Jun 2012 11:22:56 -0700

<no hat>

The message title is deliberately provocative, but does indicate the path
that I think we should follow for the document.  Specifically what I would
like to do is to remove the non AEAD algorithms and replace them with AEAD
algorithms that are, more or less, equivalent.  This means that I would like
define three new algorithms AES128-HS256, AES256-HS256 and AES512-HS512 that
are AEAD algorithms.

Advantages:

1.  The header is smaller as we can eliminate the "int:" field
2.  We make it clear that non-AEAD algorithms are not permitted and put it
on the algorithm definer and not on the implementer to fix the problem if
the proposed algorithm is not an AEAD algorithm.
3.  It makes the encryption document simpler as there is now only one
encryption/decrypt set of steps to follow.
4.  The KDF moves from JWE to JWA where it more properly belongs
5.  The KDF now becomes an implicit parameter of the algorithm and it is
easy to change it for an updated one later as necessary for specific
algorithms.  As it currently stands there is no easy way to change this on
an algorithm by algorithm basis.  This means that we can use SHA-256 for the
first two algorithms and SHA-512 for the last one - this means that we don't
"lose bits" in the process of doing the KDF.
6.  The test matrix becomes smaller for implementers as there is a list
rather than a matrix of possible functions to look at.

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 4 Jun 2012 10:13:27 +1000

Jim Schaad said:
> The message title is deliberately provocative, but does indicate the
> path that I think we should follow for the document.  Specifically what
> what I would like to do is to remove the non AEAD algorithms and replace
> them with AEAD algorithms that are, more or less, equivalent.  This
> means that I would like define three new algorithms AES128-HS256,
> AES256-HS256 and AES512-HS512 that are AEAD algorithms.
> 
> Advantages:
> 
> 2.  We make it clear that non-AEAD algorithms are not permitted and put
> it on the algorithm definer and not on the implementer to fix the
> problem if the proposed algorithm is not an AEAD algorithm.
> 5.  The KDF now becomes an implicit parameter of the algorithm and it
> is easy to change it for an updated one later as necessary for specific
> algorithms.  As it currently stands there is no easy way to change this
> on an algorithm by algorithm basis.  This means that we can use SHA-256
> for the first two algorithms and SHA-512 for the last one - this means
> that we don't "lose bits" in the process of doing the KDF.

I agree with this approach.
Hardwiring the KDF to use SHA-256 is a showstopper in the current approach [JWE-02], particularly with SHA-3 on the horizon.

I guess "AES512-HS512" should actually be "AES256-HS512", or better still "A256CBC-HS512" to be a bit more consistent with other names.

--
James Manger

---

From: Matt Miller <[email-masked]>
Date: Mon, 4 Jun 2012 09:37:18 -0600

> rather than a matrix of possible functions to look at.

+1

In fact, David McGrew is working on a draft that defines AEAD algorithms that re-use AES-CBC + HMAC-SHA2.

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 4 Jun 2012 09:16:08 -0700

> -----Original Message-----
> From: Matt Miller [mailto:[email-masked]]
> Sent: Monday, June 04, 2012 8:37 AM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD algorithms
> 
> > path that I think we should follow for the document.  Specifically
> > what I would like to do is to remove the non AEAD algorithms and
> > replace them with AEAD algorithms that are, more or less, equivalent.
> > This means that I would like define three new algorithms AES128-HS256,
> > 1.  The header is smaller as we can eliminate the "int:" field 2.  We
> > make it clear that non-AEAD algorithms are not permitted and put it on
> > the algorithm definer and not on the implementer to fix the problem if
> > 4.  The KDF moves from JWE to JWA where it more properly belongs 5.
> > The KDF now becomes an implicit parameter of the algorithm and it is
> > algorithms.  As it currently stands there is no easy way to change
> > this on an algorithm by algorithm basis.  This means that we can use
> > SHA-256 for the first two algorithms and SHA-512 for the last one -
> > this means that we don't "lose bits" in the process of doing the KDF.
> > 6.  The test matrix becomes smaller for implementers as there is a
> > list rather than a matrix of possible functions to look at.
> 
> +1
> 
> In fact, David McGrew is working on a draft that defines AEAD algorithms
that
> re-use AES-CBC + HMAC-SHA2.

There is also RFC6576 by Peter Gutmann which does the same thing in a CMS
context.

Jim

---

From: Matt Miller <[email-masked]>
Date: Mon, 4 Jun 2012 10:30:57 -0600

> There is also RFC6576 by Peter Gutmann which does the same thing in a CMS

Did you mean RFC6476 "Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS)"?

In any case, thank you for the reference; I could not find that earlier!

- m&m

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 4 Jun 2012 09:37:14 -0700

> Sent: Monday, June 04, 2012 9:31 AM
> To: Jim Schaad
> Cc: [email-masked]
> >>> 1.  The header is smaller as we can eliminate the "int:" field 2.
> >>> We make it clear that non-AEAD algorithms are not permitted and put
> >>> 3.  It makes the encryption document simpler as there is now only
> >>> one encryption/decrypt set of steps to follow.
> > There is also RFC6576 by Peter Gutmann which does the same thing in a
> > CMS context.
> >
> > Jim
> 
> Did you mean RFC6476 "Using Message Authentication Code (MAC)
> Encryption in the Cryptographic Message Syntax (CMS)"?
> 

Yes - typo on my part.

---

From: John Bradley <[email-masked]>
Date: Mon, 4 Jun 2012 12:59:18 -0400

I think there is some merit in having:
AES128CBC + HMAC-SHA256 + SHA256KDF   = A128CBC
AES256CBC + HMAC-SHA256 + SHA256KDF   = A256CBC
AES512CNC + HMAC-SHA512 + SHA512KDF   = A512CBC

defined as composite algorithms, while keeping the HMAC as a separate element from the encrypted CMK, as we have it now.

Using the other RFC lags can be done as later extensions.  The current CBC + HMAC may not be sexy but it works, and is easy to implement.

John B.

On 2012-06-04, at 12:37 PM, Jim Schaad wrote:

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

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 4 Jun 2012 12:13:00 -0700

I am afraid I don't understand your position.  Are you saying keep things
the way they are or not?

Jim

> From: John Bradley [mailto:[email-masked]]
> Sent: Monday, June 04, 2012 9:59 AM
> To: Jim Schaad
> Cc: [email-masked]
> defined as composite algorithms, while keeping the HMAC as a separate
> element from the encrypted CMK, as we have it now.
> 
> Using the other RFC lags can be done as later extensions.  The current CBC
+
> HMAC may not be sexy but it works, and is easy to implement.
> 
> John B.
> 
> 5.

---

From: Mike Jones <[email-masked]>
Date: Mon, 4 Jun 2012 19:26:21 +0000

I won't claim to be able to your question to John, but I will  make a related observation.  Both you and John suggested that SHA-512 should be used with the KDF when the block encryption algorithm is AES CBC with 512 bit keys.

To my knowledge, the supported key sizes for AES do not include 512 bits - they are 128, 192, or 256 bits.  For those key sizes, I believe that HMAC SHA-256 is sufficient, as no bits will be "lost".

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, June 04, 2012 12:13 PM
To: 'John Bradley'
Cc: [email-masked]
Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD algorithms

I am afraid I don't understand your position.  Are you saying keep things the way they are or not?

Jim

+
> >>>>> The message title is deliberately provocative, but does indicate 
> >>>>> the path that I think we should follow for the document.  
> >>>>> Specifically what I would like to do is to remove the non AEAD 
> >>>>> algorithms and replace them with AEAD algorithms that are, more 
> >>>>> or less,
equivalent.
> >>>>> We make it clear that non-AEAD algorithms are not permitted and 
> >>>>> put it on the algorithm definer and not on the implementer to 
> >>>>> fix the problem if the proposed algorithm is not an AEAD algorithm.
> >>>>> 3.  It makes the encryption document simpler as there is now 
> >>>>> only one encryption/decrypt set of steps to follow.
> >>>>> The KDF now becomes an implicit parameter of the algorithm and 
> >>>>> it is easy to change it for an updated one later as necessary 
> >>>>> for specific algorithms.  As it currently stands there is no 
> >>>>> easy way to change this on an algorithm by algorithm basis.  
> >>>>> This means that we can use
> >>>>> SHA-256 for the first two algorithms and SHA-512 for the last 
> >>>>> one - this means that we don't "lose bits" in the process of 
> >>>>> doing the
KDF.
> >>>>> 6.  The test matrix becomes smaller for implementers as there is 
> >>>>> a list rather than a matrix of possible functions to look at.
> >>>>
> >>>> +1
> >>>>
> >>> There is also RFC6576 by Peter Gutmann which does the same thing 
> >>> in a CMS context.
> >>>
> >>> Jim
> >>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 4 Jun 2012 13:32:50 -0700

You are correct about the key sizes of AES and I was wrong.  I was not
paying full attention to that when I wrote the email and was thinking in
terms of matching the hash sizes rather than the AES sizes.  I believe that
this means we could limit to one HMAC algorithm w/ the three AES algorithms
for the initially defined algorithms.

However in terms of the number of bits "lost" that would depend on the
number of bits that were specified as the input to the KDF algorithm.  One
could say that AES256-HS512 takes a CEK of 512 bits that is then processed
to get a 256 bit AES key and a 512 bit HMAC key.  If this was then case then
one could claim that bits are lost.  I would actually recommend this
approach if we really wanted to have a 512 bit integrity value with 256 bit
AES.

Jim

> From: Mike Jones [mailto:[email-masked]]
> Sent: Monday, June 04, 2012 12:26 PM
> To: Jim Schaad; 'John Bradley'
> Cc: [email-masked]
> Subject: RE: [jose] Discussion Topic - Lets kill all non AEAD algorithms
> 
> I won't claim to be able to your question to John, but I will  make a
related
> observation.  Both you and John suggested that SHA-512 should be used with
> the KDF when the block encryption algorithm is AES CBC with 512 bit keys.
> 
> To my knowledge, the supported key sizes for AES do not include 512 bits -
> they are 128, 192, or 256 bits.  For those key sizes, I believe that HMAC
SHA-
> 256 is sufficient, as no bits will be "lost".
> 
> 				Best wishes,
> 				-- Mike
> 
the
> way they are or not?

---

From: John Bradley <[email-masked]>
Date: Mon, 4 Jun 2012 20:38:08 -0400

Yes while there is rijndael with 512 bit keys it is not NIST approved as AES.

If we are going to allow mixing integrity length and encryption key length then we are probably better off specifying them separately as they are now.

AES 256 has 256 bits of security as has HMAC-SHA256. (SHA256 for signatures is only 128 bits of security, confusing isn't it)

For our AES-CBC MTI I would keep the HMAC SHA256, the KDF hash SHA256, and specify it as a single lag dropping the int parameter.

Thus giving us:
A128CBC  =  AES128CBC + HMAC-SHA2256 + KDF SHA256
A256CBC  =  AES256CBC + HMAC-SHA2256 + KDF SHA256

So it would only drop the now unnecessary int parameter and allow moving the KDF to algs.

Later we could add A256CBC3 when we have SHA 3 if we need to.

John

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 5 Jun 2012 08:56:52 -0400

The McGrew reference is:
<http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1-01>

I find Dave's document slightly nicer because 
(1) It doesn't require a KDF (it just specifies each key separately); and
(2) It appends the MAC to the ciphertext, rather than requiring a separate field

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 6 Jun 2012 12:07:17 +1000

>>> In fact, David McGrew is working on a draft that defines AEAD
>>> algorithms that re-use AES-CBC + HMAC-SHA2.
>>>

> (2) It appends the MAC to the ciphertext, rather than requiring a

I like draft-mcgrew-aead-aes-cbc-hmac-sha1 as well.
The draft is over 3 years old. Has it been abandoned?
Is there an IETF list discussing it?

The simplicity of just splitting a master key into encryption & MAC keys is appealing. That simplicity almost overcomes my concern that some implementations will not be careful enough in only using a given secret with a single algorithm. It would be insecure if the same secret was split differently based on the alg id in a received message -- and I'm not that confident that a Security Considerations warning would be sufficient to avoid this.

Now I just need to understand the difference between a nonce and an IV.

--
James Manger

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 5 Jun 2012 22:47:58 -0400

> Now I just need to understand the difference between a nonce and an IV.

Dave tells me he's working on reviving it.  But obviously, it's not an RFC yet, so standard caveats apply.

--Richard

---

From: John Bradley <[email-masked]>
Date: Wed, 6 Jun 2012 11:59:04 -0400

Using a KDF to create separate encryption and integrity values is a perfectly fine way to do it.

We can add other algorithms later.   We have people and products waiting for this.

If we wait for David or others,  people will have to go forward without JOSE. 

Combining the symmetric encryption & integrity algorithm into a single value is fine, and not a significant code change in most cases.

Waiting for additional algorithms is not.  

The lag from David's RFC can be added later if there is traction for it.

John B.

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 6 Jun 2012 16:04:55 +0000

This can be a big code change and puts the burden on the developer until the libraries can catch up, also there are cases where I'm signing encrypted content and would not like to be forced into KDF

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, June 06, 2012 8:59 AM
To: Manger, James H
Cc: [email-masked]
Subject: Re: [jose] Discussion Topic - Lets kill all non AEAD algorithms

John B.

On 2012-06-05, at 10:07 PM, Manger, James H wrote:

>>>> There is also RFC6576 by Peter Gutmann which does the same thing in 
>>>> a CMS context.
> 
>> The McGrew reference is: