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
