Unfortunately, the minutes from that session don't appear very clear on the point [1]. As I recall, people were OK with going AEAD-only precisely because it would be so easy to do with draft-mcgrew-aead-aes-cbc-hmac-sha2. Since it seems like a bad idea to have people going around inventing their own AEAD algorithms (as David notes below), it would make sense to at least RECOMMEND that the McGrew draft be the way people build AEAD algorithms from non-AEAD primitives, when no AEAD algorithms are available natively.
[1] <http://tools.ietf.org/wg/jose/minutes?item=minutes-84-jose.html> On Nov 12, 2012, at 3:09 PM, Michael Jones <[email protected]> wrote: > I believe that you're slightly misstating the consensus below. Yes, there > was consensus that we should move to only authenticated encryption > algorithms. The drafts have already done this. There was not consensus to > spedifically use the algorithms in draft-mcgrew-aead-aes-cbc-hmac-sha2. If > there was, they would already be in the drafts, as the drafts have been > updated to incorporate all consensus decisions since then. > > There *was* an informal agreement that, should someone want to, they could > add the algorithms in draft-mcgrew-aead-aes-cbc-hmac-sha2 to the JWA > algorithms registry, and then people could also use them, should they so > desire. It's a potentially subtle, but important distinction. > > Best wishes, > -- Mike > From: [email protected] > To: [email protected] > Date: Mon, 12 Nov 2012 16:43:21 +0000 > CC: [email protected] > Subject: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key > > Hi Mike, > > Please see <DAM> inline. > > From: Michael Jones <michael_b_jones at hotmail.com> > To: <james.h.manger at team.telstra.com>, <jose at ietf.org> > Date: Sun, 11 Nov 2012 17:30:54 -0800 > In-reply-to: <255B9BB34FB7D647A506DC292726F6E11500331CA9 at > WSMSG3153V.srv.dir.telstra.com> > References: <BAY171-W32DD53461B3DF4235F053DB7680 at phx.gbl>, > <255B9BB34FB7D647A506DC292726F6E11500331CA9 at WSMSG3153V.srv.dir.telstra.com> > List-id: Javascript Object Signing and Encryption <jose.ietf.org> > > 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. > > <DAM> > draft-mcgrew-aead-aes-cbc-hmac-sha2 does use exactly the same interface as > AES-GCM, RFC 5116, and the other AEAD algorithms that make use of that > interface. > To make this more clear, I can make the following addition. Section 2.1 > starts out as "We briefly recall the encryption interface defined in Section > 2 of [RFC5116]." I will add "which is used by all of the algorithms > defined in this note". > </DAM> > > 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. > > <DAM> > draft-mcgrew-aead-aes-cbc-hmac-sha2 has all of the required steps for > authenticated encryption, and does not have any extraneous steps. Things > like plaintext padding need to be specified, and it is critical to have the > length of the associated data included in the MAC input (see Section 6, third > paragraph, of draft-mcgrew). > > The fact that implementations might get these details wrong is why they > belong in the crypto algorithm, and not in the JOSE implementation. > Consider, for instance, that with the AEAD approach these details would get > test coverage from the AEAD test cases; otherwise, there are details that > would go untested. > > </DAM> > > 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. > > <DAM> > When JOSE met at IETF84, the consensus of the room was to use AEAD and > draft-mcgrew-aead-aes-cbc-hmac-sha2, and omit unauthenticated encryption. > That's what JOSE should do, as it is the technically best solution. I will > ask Kevin Igoe to move draft-mcgrew forward to RFC. > > </DAM> > > 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. > > <DAM> > draft-mcgrew-aead-aes-cbc-hmac-sha2 uses the same interface as does > AEAD_AES_128_GCM; see Section 5.1 of RFC 5116. > > David > </DAM> > > -- Mike > > > From: James.H.Manger at team.telstra.com > > To: michael_b_jones at hotmail.com; jose at ietf.org > > 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 > > > > > 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? > > > > > > 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2 > > > > -- > > James Manger > > > > _______________________________________________ jose mailing list > [email protected] https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
