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

Believe me, if there were out of the box AEAD algorithm implementations available in most crypto libraries, I'd be eager to use them.  As it is though, all we can count on really being there are AES CBC and SHA-2. The JWE algs are intended to be as easy to securely and interoperably implement with those building blocks as possible.

Remember that implementers will be building these algorithms from those parts themselves. A key JOSE goal is making that prospect both approachable and attractive.  That's my primary motivation in all of these (very useful) discussions.  I'm sure that's a goal we all share.

Cheers,
-- Mike

Sent from my Windows Phone
________________________________
From: David McGrew (mcgrew)
Sent: 11/12/2012 3:20 PM
To: Michael Jones; cfrg@irtf.org; jose@ietf.org
Cc: Paterson, Kenny
Subject: Re: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

From: Michael Jones <michael_b_jones@hotmail.com<mailto:michael_b_jones@hotmail.com>>
Date: Monday, November 12, 2012 3:25 PM
To: Cisco Employee <mcgrew@cisco.com<mailto:mcgrew@cisco.com>>, "cfrg@irtf.org<mailto:cfrg@irtf.org>" <cfrg@irtf.org<mailto:cfrg@irtf.org>>, "jose@ietf.org<mailto:jose@ietf.org>" <jose@ietf.org<mailto:jose@ietf.org>>
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:mcgrew@cisco.com]
Sent: Monday, November 12, 2012 11:43 AM
To: Mike Jones; cfrg@irtf.org<mailto:cfrg@irtf.org>; jose@ietf.org<mailto: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<mailto:Michael.Jones@microsoft.com>>
Date: Monday, November 12, 2012 1:55 PM
To: Cisco Employee <mcgrew@cisco.com<mailto:mcgrew@cisco.com>>, "cfrg@irtf.org<mailto:cfrg@irtf.org>" <cfrg@irtf.org<mailto:cfrg@irtf.org>>, "jose@ietf.org<mailto:jose@ietf.org>" <jose@ietf.org<mailto: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<mailto:mcgrew@cisco.com>
To: cfrg@irtf.org<mailto:cfrg@irtf.org>; jose@ietf.org<mailto:jose@ietf.org>
Date: Mon, 12 Nov 2012 18:20:57 +0000
CC: Kenny.Paterson@rhul.ac.uk<mailto: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><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 jose@ietf.org<mailto:jose@ietf.org> https://www.ietf.org/mailman/listinfo/jose