From: Michael Jones
<[email protected]<mailto:[email protected]>>
Date: Monday, November 12, 2012 3:25 PM
To: Cisco Employee <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: RE: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version
01
OK, I admit that the way I phrased my request may not be exactly in line with
the way the “AEAD” terminology is used. I can correct that. That’s syntax. I
was using “AEAD” as a shorthand for the working group’s decision to use only
authenticated encryption algorithms – not to mean the particular combined
representation of those parameters apparently specified in the AEAD draft. I
will correct the terminology usage in the next revision of the JOSE
specifications.
The semantic point remains that it’s cleaner and more flexible to have the Key,
the Plaintext, IV, and “additional authenticated data” parameters all be
separate inputs and the Ciphertext and “authentication tag” all be separate
outputs. In JOSE’s particular use case, that would be a significantly better
match and easier for implementers to use.
JOSE already has a way of combining the inputs and outputs that’s inherent to
its representation, and it doesn’t match the one you’ve specified. GCM, CTR,
and the current JOSE-specified algorithms are a great fit for this, as they can
directly use that representation. The AEAD pattern you cite requires
disassembly of the components of the AEAD-specific representation to be able to
use the combinations already present in the JOSE representations and then
reassembly at decryption time. That’s just more work for implementers, and
it’s not semantically necessary work.
One could just as easily argue that the unnecessary work comes from the fact
that draft-ietf-jose-json-web-algorithms-07 defines its own AEAD algorithms,
which do not use the RFC 5116 interface. The draft confusingly references
that RFC after it defines AEAD, but then does something different. If the
plan is really going to be for the JOSE WG to define its own AEAD algorithms
that are incompatible (which I hope is not the case), the differences and
motivation deserve to be documented.
The motivation for 5116 incorporating the authentication data into the
ciphertext was to simplify the interface and move more of the crypto details
under the crypto interface. These are still valid motivations, though at this
point the most important reason to use the interface is to avoid gratuitous
incompatibility. Other protocols have not had any trouble in using the 5116
interface; See RFC 5288 (TLSv1.2) Section 6.2.3.3, RFC 5647 (SSH GCM), or
draft-ietf-avtcore-srtp-aes-gcm, for instance.
Are you open to specifying versions of your algorithms that don’t require a
particular combination method for the parameters, but instead leave the
combination up to the use case? I’m fine with you also specifying a specific
combination method as an optional feature of the specification. But it
shouldn’t be part of the algorithm definition, just like it isn’t for GCM.
I am not dogmatically opposed to other interfaces, but the best solution here
is for JOSE to actually use the 5116 interface, like this:
X.Y. Authenticated Encryption
This section defines the specifics of encrypting the JWE Plaintext
Using the Authenticated Encryption with Associated Data (AEAD)
as defined in RFC 5116. The authenticated encryption operation
has four inputs, as follows:
The secret key is the CMK.
The associated data is the bytes of the ASCII representation of the
concatenation of
the Encoded JWE Header, a period ('.') character, the Encoded JWE
Encrypted Key, a second period character ('.'), and the Encoded JWE
Initialization Vector, per Section 5 of the JWE specification.
The plaintext , which contains the data to be encrypted and
authenticated.
A nonce N, with a length of either 0 or 96 bits. If the length
is zero, the nonce is omitted. Otherwise, the nonce
is as described in Section 3 of RFC 5116.
There is a single output, the Ciphertext.
The "enc" header parameter values are set as follows:
"enc" Algorithm
-----------------------------------------------------------------------
"A128GCM" AEAD_AES_128_GCM
"A256GCM" AEAD_AES_256_GCM
"A128CHS" AEAD_AES_128_CBC_HMAC_SHA_256
"A256CHS" AEAD_AES_256_CBC_HMAC_SHA_512
"A128SIV" AEAD_AES_SIV_CMAC_256
"A256SIV" AEAD_AES_SIV_CMAC_384
See <http://www.iana.org/assignments/aead-parameters/aead-parameters.xml>
for the
references corresponding to these symbolic names.
If we want to make actual progress on crypto interfaces, the thing that would
be worth doing is defining a simpler interface that moves the nonce details
into the ciphertext (and thus away from the user). Moving the authentication
data out of the ciphertext would be movement in the wrong direction, in my
opinion.
David
Best wishes,
-- Mike
From: David McGrew (mcgrew) [mailto:[email protected]]
Sent: Monday, November 12, 2012 11:43 AM
To: Mike Jones; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version
01
Hi Mike,
From: Mike Jones
<[email protected]<mailto:[email protected]>>
Date: Monday, November 12, 2012 1:55 PM
To: Cisco Employee <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version
01
As background, if there was a version of this spec that did not assume that the
parameters would be concatenated together in a specific way, but left them as
independent inputs and outputs, as AES GCM and AES CTR do, it would be a better
match for JOSE’s use case.
I believe that what you are referring to is the inclusion of the authentication
tag in the authenticated ciphertext. This is not just a property of
draft-mcgrew-aead-aes-cbc-hmac-sha2; it is a feature of all 19 of the AEAD
algorithms that have been defined so far. For comparison,
draft-mcgrew-aead-aes-cbc-hmac-sha2 says
The AEAD Ciphertext consists of the string S, with the string T
appended to it. This Ciphertext is returned as the output of the
AEAD encryption operation.
Where S is the ciphertext and T is the authentication tag. RFC 5116 says
"The AEAD_AES_128_GCM ciphertext is formed
by
appending the authentication tag provided as an output to the GCM
encryption operation to the ciphertext that is output by that
operation."
David
-- Mike
________________________________
From: [email protected]<mailto:[email protected]>
To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Date: Mon, 12 Nov 2012 18:20:57 +0000
CC: [email protected]<mailto:[email protected]>
Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01
Hi,
There is a new version of "Authenticated Encryption with AES-CBC and HMAC-SHA",
and I would appreciate your review. It is online at
<https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?include_text=1><https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?include_text=1%3e>
The diff between the current and the previous version is available at
<http://www.ietf.org/rfcdiff?url2=draft-mcgrew-aead-aes-cbc-hmac-sha2-01><http://www.ietf.org/rfcdiff?url2=draft-mcgrew-aead-aes-cbc-hmac-sha2-01%3e>
This draft has been proposed for use in the JOSE WG
<http://datatracker.ietf.org/wg/jose/><http://datatracker.ietf.org/wg/jose/%3e>
, where its adoption would allow the working group to omit "raw"
unauthenticated encryption, e.g. AES-CBC, and only include authenticated
encryption. Thus I am asking for your help in making
John Foley generated test cases that correspond to the current version of the
draft, but I didn't include these in the draft because I did not yet get
confirmation from a second independent implementation. With hope, there will
not be any need for any normative changes, and I will include these after I get
confirmation.
Thanks,
David
_______________________________________________ jose mailing list
[email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
