Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request

From: "Jim Schaad" <[email-masked]>
Date: Thu, 4 Apr 2013 16:51:07 -0700

<chair> 

At the request of the editors, this is a formal consensus call on the first
item in the list below.  If there are objects to use a single long key
rather than a KDF function for the AES-CBC/HMAC algorithm please speak up
now.  To date nobody has said that I was wrong to assume the consensus on
that item.

Call ends in one week.

Jim

> -----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
> 
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Dick Hardt <[email-masked]>
Date: Thu, 4 Apr 2013 16:57:06 -0700

Having already implemented the KDF in the spec, I have a minor preference to keep it how it is, but no animals will need to be sacrificed if I have to change.

---

From: Mike Jones <[email-masked]>
Date: Fri, 5 Apr 2013 00:13:33 +0000

I'm in favor of the change.  I believe that this equivalent to issue http://trac.tools.ietf.org/wg/jose/trac/ticket/3 - correct?

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Thursday, April 04, 2013 4:51 PM
To: [email-masked]
Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request

<chair> 

At the request of the editors, this is a formal consensus call on the first item in the list below.  If there are objects to use a single long key rather than a KDF function for the AES-CBC/HMAC algorithm please speak up now.  To date nobody has said that I was wrong to assume the consensus on that item.

Call ends in one week.

Jim

Jim
issue
the
resolving
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.
all
> 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.
all
> 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.
different
might
> 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?
> 
situations
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

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Apr 2013 21:53:39 -0400

I support the change.

---

From: Russ Housley <[email-masked]>
Date: Fri, 5 Apr 2013 09:46:16 -0400

I have a minor preference for the KDF.  The KDF eliminates any bias in the base key, and the KDF support the use of a base key with just enough entropy to be secure.

Russ

---

From: "Peck, Michael A" <[email-masked]>
Date: Sun, 7 Apr 2013 19:32:03 +0000

I prefer using a KDF, as I think the approach of using a long key over-complicates key management by requiring generation and transport of a longer key than necessary, and it may also provide a false sense of the overall security level.

As previously discussed, the Concat KDF is not appropriate, but there are other NIST KDFs that seem acceptable for this key expansion purpose.
For instance, the "KDF in Counter Mode" in NIST SP 800-108 Section 5.1, with the PRF algorithm set to the same HMAC algorithm used in the corresponding AEAD algorithm.  (i.e. use HMAC-SHA-256 as PRF with AES-128 + HMAC-SHA-256, and use HMAC-SHA-512 as PRF with AES-256 + HMAC-SHA-512).

For example, for AES-128 + HMAC-SHA-256, where "key" is an inputted 128-bit "master" key:
Expanded key = HMAC-SHA-256(key, 0x00 0x00 0x00 0x01 | "A128CBC+HS256" | 0x00 | 0x00 0x00 0x01 0x00)
AES key = first 128 bits of expanded key
HMAC key = second 128 bits of expanded key

If JOSE chooses to use draft-mcgrew-aead-aes-cbc-hmac-sha2, I think it would be worth discussing with the draft authors whether they are interested in performing the KDF in the AEAD algorithm itself (for example, input a 128-bit key into their AEAD_AES_128_CBC_HMAC_SHA_256 and have it be responsible for deriving the 128-bit AES key and 128-bit HMAC key).

Mike

>Jim Schaad
>Sent: Thursday, April 04, 2013 7:51 PM
>To: [email-masked]
>are

---

From: Dick Hardt <[email-masked]>
Date: Sun, 7 Apr 2013 21:47:10 -0700

FWIW: I'd strongly prefer a longer key than a different KDF scheme.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 8 Apr 2013 15:33:28 +0000

+1 on a longer key.

- m&m

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

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 9 Apr 2013 08:29:54 +0900

Concat is what McGrew algorithm does it, is it not? I support the move.

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Edmund Jay <[email-masked]>
Date: Mon, 8 Apr 2013 23:23:18 -0700 (PDT)

+1 in support of longer key.

-- Edmund

________________________________
From: Jim Schaad <[email-masked]>
To: [email-masked]
Sent: Thu, April 4, 2013 4:52:01 PM
Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request

<chair> 

Call ends in one week.

Jim

Jim
issue
the
resolving
done.
all
all
for
different
might
situations
is
field by

---

From: John Bradley <[email-masked]>
Date: Tue, 9 Apr 2013 07:06:41 -0400

Concatenating the keys together as in McGrew, not the Concat KDF as in the current spec?

I think I know what you mean but just double checking.

John B.