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.

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.

                                                            Best
wishes,                                                            --
Mike

From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com] 

Sent: Monday, November 12, 2012 11:43 AM

To: Mike Jones; cfrg@irtf.org; jose@ietf.org

Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA,
version 01

Hi Mike,

From: Mike Jones <Michael.Jones@microsoft.com>

Date: Monday, November 12, 2012 1:55 PM

To: Cisco Employee <mcgrew@cisco.com>,
"cfrg@irtf.org" <cfrg@irtf.org>, "jose@ietf.org" <jose@ietf.org>

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: mcgrew@cisco.com
To: cfrg@irtf.org; jose@ietf.org
Date: Mon, 12 Nov 2012 18:20:57 +0000
CC: Kenny.Paterson@rhul.ac.uk
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> 
  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>

This draft has been proposed for use in the JOSE WG <http://datatracker.ietf.org/wg/jose/> , 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
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose 		 	   		  