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

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Mon, 12 Nov 2012 18:20:57 +0000

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

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Mon, 12 Nov 2012 19:42:36 +0000

Hi Mike,

From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 12, 2012 1:55 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of David McGrew (mcgrew)
Sent: Monday, November 12, 2012 10:21 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Cfrg] 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

Thanks,

David

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 12 Nov 2012 12:21:13 -0800 (PST)

Hi Mike,

> From: Mike Jones
> <[email-masked]<mailto:[email-masked]>>
> To: Cisco Employee <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>
> 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 encourage you to look into SIV mode, an AEAD scheme found in
RFC 5297. SIV was defined by Rogaway and Shrimpton (in a paper
found in the RFC) and is provably secure.

  It takes a vector of input as additional authenticated data which will
be authenticated, and a plaintext which will be authenticated and
encrypted. It does not assume that the parameters are concatenated
together, it's just a vector of separate inputs.

  Additionally, SIV mode does not require a random IV/nonce. It works
just fine if you have one, and it won't collapse if it is repeated (as GCM
does) or is predictable (as CBC-HMAC does), and it works if you don't
have, or want to have, one. In that fashion it is more robust than other
AEAD schemes. The downside is that it's slower than GCM but is probably
faster than CBC-HMAC with SHA2.

  regards,

  Dan.

---

From: Michael Jones <[email-masked]>
Date: Mon, 12 Nov 2012 12:25:04 -0800

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:[email-masked]] 

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

To: Mike Jones; [email-masked]; [email-masked]

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

Hi Mike,

From: Mike Jones <[email-masked]>

To: Cisco Employee <[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

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-masked]
To: [email-masked]; [email-masked]
Date: Mon, 12 Nov 2012 18:20:57 +0000
CC: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Mon, 12 Nov 2012 23:19:48 +0000

From: Michael Jones <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 12, 2012 3:25 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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-masked]]
Sent: Monday, November 12, 2012 11:43 AM
To: Mike Jones; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

Hi Mike,

David

                                                            -- Mike

________________________________
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Date: Mon, 12 Nov 2012 18:20:57 +0000
CC: [email-masked]<mailto:[email-masked]>
Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

Hi,

_______________________________________________ jose mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/jose

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Mon, 12 Nov 2012 23:39:33 +0000

On 11/12/12 3:21 PM, "Dan Harkins" <[email-masked]> wrote:

>> would be a better match for JOSE¹s use case.
>

AES-SIV is in several ways technically superior to AES-CBC-HMAC-SHA.
However, the motivation to use the latter algorithm is its widespread
availability, as I understand it.   Mike and some other folks did a survey
of what crypto that is available.  (Perhaps someone can send a reference,
it is a good survey.)

Despite SIV's flexibility, it doesn't address Mike's complaint, because it
does not have an authentication tag that is separate from the ciphertext.
 Instead, it has the synthetic IV (which acts like an auth tag) combined
with the ciphertext.

As an aside, if SIV is used for JOSE, it can use the RFC 5116 interface
(see Sections 6.1-6.3 of the SIV RFC) and essentially would need to do so.

David

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 12 Nov 2012 16:06:44 -0800 (PST)

Hi David,

> of what crypto that is available.  (Perhaps someone can send a reference,

  Well, there is no widespread availability of AES-CBC-HMAC-SHA either.
There may be availability of AES-CBC and HMAC-SHA separately but then
there is, probably, availability of AES-CTR and AES-CMAC too and that
is all SIV is, a provably secure construction of those two primitives.

>  Instead, it has the synthetic IV (which acts like an auth tag) combined

  Ahh, I missed that. But I think that is probably a trivial complaint of
any 5116 AEAD scheme. It should be straightforward to extract the
specific sub-string from the bitstring returned by any of the appropriate
schemes if he wants to copy the IV/MAC/tag/whatever into a field that
is separate from the encrypted plaintext.

> (see Sections 6.1-6.3 of the SIV RFC) and essentially would need to do so.

  Good point!

  Regards,

  Dan.

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 13 Nov 2012 17:33:30 +1100

+10

This is much clearer, and much more suitable for separating what goes in a JOSE library vs what goes in a general-purpose crypto library. Even if a JOSE library needs to implement parts of the crypto today because native AEAD support is not yet present, this solution makes it much more likely JOSE will be compatible with native AEAD as it becomes available. I think it is unlikely that native AEAD support (once available) would support both JOSE and draft-mcgrew variants of AEAD-from-AES-CBC-HMAC. The draft-mcgrew variant has a better chance of being implemented because it doesn’t impose a 33% performance penalty for the MACing part, and the other differences are trivial.

The fact that some existing AEAD algorithms (SIV [RFC 5297]) don’t produce a separate authentication tag is a clear indication that a single ciphertext output is a better general model for AEAD in JOSE than separate ciphertext and integrity values as in JWE today.

Editorials:
“JWE Initialization Vector” should be renamed “JWE Nonce”.
The nonce paragraph needn’t hardwire 2 lengths (0 and 96 bits) – leave it to each alg to specify.
The table can include key and nonce sizes.
    "enc"                key size    nonce size  Algorithm
    -----------------------------------------------------------------------
    "A128GCM"   16 bytes    12 bytes     AEAD_AES_128_GCM
    "A256GCM"   32 bytes    12 bytes     AEAD_AES_256_GCM
     "A128CHS"     48 bytes     0 bytes      AEAD_AES_128_CBC_HMAC_SHA_256
     "A256CHS"     64 bytes     0 bytes      AEAD_AES_256_CBC_HMAC_SHA_512

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of David McGrew (mcgrew)
Sent: Tuesday, 13 November 2012 10:20 AM
To: Michael Jones; [email-masked]; [email-masked]
Subject: Re: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

…

    "enc"                  Algorithm

      See <http://www.iana.org/assignments/aead-parameters/aead-parameters.xml><http://www.iana.org/assignments/aead-parameters/aead-parameters.xml%3e> for the
     references corresponding to these symbolic names.

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Tue, 13 Nov 2012 16:31:42 +0000

Hi James,

From: <Manger>, James H <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 13, 2012 1:33 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

+10

Editorials:

Thanks for the good suggestions (agreed on all of them) and support.

Regards,

David

--
James Manger

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of David McGrew (mcgrew)
Sent: Tuesday, 13 November 2012 10:20 AM
To: Michael Jones; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

…

    "enc"                  Algorithm

---

From: Mike Jones <[email-masked]>
Date: Mon, 12 Nov 2012 18:55:17 +0000

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.

                                                            -- Mike

Hi,

Thanks,

David

---

From: Russ Housley <[email-masked]>
Date: Sun, 18 Nov 2012 07:45:29 -0500

Have you looked at the algorithm in RFC 6476?  While the discussion is CMS-specific, the algorithm could be used with another syntax.

Russ

On Nov 12, 2012, at 1:55 PM, Mike Jones wrote:

> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: "Tolga Acar" <[email-masked]>
Date: Sun, 18 Nov 2012 10:44:56 -0800

Quick feedback on the draft

.         Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is
clear this is not new, but a reuse of an existing padding scheme.

.         Section 2.2, step 3. When MAC verification fails, the draft
recommends halting the operation before CBC decryption. We have seen timing
and error-code based attacks against TLS' MAC-then-Encrypt scheme. I realize
that the draft is prescribing E-t-M. Nonetheless, considering a potential
flaw in HMAC-SHA2 series (I don't know of any, but .), I'd suggest not
halting the operation even after MAC check fails, but continuing on to CBC
decryption, and then returning an error that doesn't distinguish between a
MAC and a decryption (pad check) error. Yes, this would consume more CPU
cycles only to waste them *under an attack*, which is not necessarily bad.

.         Section 2.2, step 5. Unspecified error case of invalid padding
(link to my comment above).

Best,

-          Tolga

From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ
Housley
Sent: Sunday, November 18, 2012 4:45 AM
To: Mike Jones
Cc: IRTF CFRG; [email-masked]
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA,
version 01

Have you looked at the algorithm in RFC 6476?  While the discussion is
CMS-specific, the algorithm could be used with another syntax.

Russ

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.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
David McGrew (mcgrew)
Sent: Monday, November 12, 2012 10:21 AM
To: [email-masked]; [email-masked]
Subject: [Cfrg] 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/?inclu
de_text=1
<https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?inclu
de_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

---

From: Mike Jones <[email-masked]>
Date: Tue, 20 Nov 2012 01:48:43 +0000

Thanks for the pointer, Russ.  This is a useful point of reference in several regards.

                                                                -- Mike

From: Russ Housley [mailto:[email-masked]]
Sent: Sunday, November 18, 2012 4:45 AM
To: Mike Jones
Cc: IRTF CFRG; [email-masked]
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

Russ

                                                            -- Mike

Hi,

Thanks,

David
_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
http://www.irtf.org/mailman/listinfo/cfrg

---

From: David Jacobson <[email-masked]>
Date: Mon, 19 Nov 2012 20:59:36 -0800

I think I'd argue the other way on continuing on on when the MAC fails.

One big advantage of encrypt-then-MAC is that the receiving end does 
MACverify-then-decrypt.  If the message has been tampered with, the MAC 
fails to verify and we never even enter the decryption stuff, thus there 
is never even the possibility of padding oracles, timing attacks, etc.  
If you go ahead with the decryption, you risk revealing something.

    --David

On 11/18/2012 10:44 AM, Tolga Acar wrote:
> ·Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is clear 
> this is not new, but a reuse of an existing padding scheme.
>
> ·Section 2.2, step 3. When MAC verification fails, the draft 
> recommends halting the operation before CBC decryption. We have seen 
> timing and error-code based attacks against TLS' MAC-then-Encrypt 
> scheme. I realize that the draft is prescribing E-t-M. Nonetheless, 
> considering a potential flaw in HMAC-SHA2 series (I don't know of any, 
> but ...), I'd suggest not halting the operation even after MAC check 
> fails, but continuing on to CBC decryption, and then returning an 
> error that doesn't distinguish between a MAC and a decryption (pad 
> check) error. Yes, this would consume more CPU cycles only to waste 
> them **under an attack**, which is not necessarily bad.
>
> ·Section 2.2, step 5. Unspecified error case of invalid padding (link 
> to my comment above).
>
> Best,
>
> -Tolga
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Russ Housley
> *Sent:* Sunday, November 18, 2012 4:45 AM
> *To:* Mike Jones
> *Cc:* IRTF CFRG; [email-masked]
> *Subject:* Re: [Cfrg] Authenticated Encryption with AES-CBC and 
> HMAC-SHA, version 01
>
> 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.
>
> -- Mike
>
> *From:[email-masked] 
> <mailto:[email-masked]>[mailto:[email-masked]]*On Behalf 
> Of*David McGrew (mcgrew)
> *Sent:*Monday, November 12, 2012 10:21 AM
> *To:[email-masked] <mailto:[email-masked]>;[email-masked] 
> <mailto:[email-masked]>
> *Subject:*[Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, 
> version 01
>
> Hi,
>
> <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://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
>
> [email-masked] <mailto:[email-masked]>

---

From: "Tolga Acar" <[email-masked]>
Date: Mon, 19 Nov 2012 22:26:55 -0800

Ø  One big advantage of encrypt-then-MAC is that the receiving end does
MACverify-then-decrypt.  If the message has been tampered with, the MAC
fails to verify and we never even enter the decryption stuff, thus there is
never even the possibility of padding oracles, timing attacks, etc.  If you
go ahead with the decryption, you risk revealing something.

I realize that is what the theory says up to a negligible probability; but
saying “never even enter decryption stuff” is practically accurate as far as
we know today. I am concerned about not yet existent weaknesses in MAC
functions (and perhaps their underlying hash functions if MAC = HMAC as in
this case), that would open an avenue for a side-channel leakage. Call me
paranoid, and say this is far-fetched.

If you go ahead with decryption regardless of a MAC failure, you will return
a failure if decryption fails. This is about MAC succeeding but decryption
failing, which ends up in a failure to be returned anyhow. If both succeeds
when they are not supposed to, then you found that negligible probability
case (or one of them).

-          Tolga

From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Jacobson
Sent: Monday, November 19, 2012 9:00 PM
To: [email-masked]
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA,
version 01

One big advantage of encrypt-then-MAC is that the receiving end does
MACverify-then-decrypt.  If the message has been tampered with, the MAC
fails to verify and we never even enter the decryption stuff, thus there is
never even the possibility of padding oracles, timing attacks, etc.  If you
go ahead with the decryption, you risk revealing something.

   --David

·         Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is
clear this is not new, but a reuse of an existing padding scheme.

·         Section 2.2, step 3. When MAC verification fails, the draft
recommends halting the operation before CBC decryption. We have seen timing
and error-code based attacks against TLS’ MAC-then-Encrypt scheme. I realize
that the draft is prescribing E-t-M. Nonetheless, considering a potential
flaw in HMAC-SHA2 series (I don’t know of any, but …), I’d suggest not
halting the operation even after MAC check fails, but continuing on to CBC
decryption, and then returning an error that doesn’t distinguish between a
MAC and a decryption (pad check) error. Yes, this would consume more CPU
cycles only to waste them *under an attack*, which is not necessarily bad.

·         Section 2.2, step 5. Unspecified error case of invalid padding
(link to my comment above).

Best,

-          Tolga

Russ

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.

                                                            -- Mike

Hi,

Thanks,

David

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Tue, 20 Nov 2012 13:10:19 +0000

I'll agree with David's position, but for a slightly different reason.  A packet with a bad MAC may mean
the decrypted PT is malicious.  Not decrypting CT with a bad MAC cryptographically enforces the policy
that questionable packets MUST NOT be released to the receiving user/processes.

Misuse of AES-CBC-HMAC-SHA (we really need a shorter name) by a well intentioned application programmer
is, in my opinion, the larger risk.  By never even decrypting questionable CT there is no chance the programmers
will, with the best of intentions,   make a security critical mistake by acting upon malicious PT.

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Jacobson
Sent: Tuesday, November 20, 2012 12:00 AM
To: [email-masked]
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

One big advantage of encrypt-then-MAC is that the receiving end does MACverify-then-decrypt.  If the message has been tampered with, the MAC fails to verify and we never even enter the decryption stuff, thus there is never even the possibility of padding oracles, timing attacks, etc.  If you go ahead with the decryption, you risk revealing something.

   --David

*         Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is clear this is not new, but a reuse of an existing padding scheme.

*         Section 2.2, step 3. When MAC verification fails, the draft recommends halting the operation before CBC decryption. We have seen timing and error-code based attacks against TLS' MAC-then-Encrypt scheme. I realize that the draft is prescribing E-t-M. Nonetheless, considering a potential flaw in HMAC-SHA2 series (I don't know of any, but ...), I'd suggest not halting the operation even after MAC check fails, but continuing on to CBC decryption, and then returning an error that doesn't distinguish between a MAC and a decryption (pad check) error. Yes, this would consume more CPU cycles only to waste them *under an attack*, which is not necessarily bad.

*         Section 2.2, step 5. Unspecified error case of invalid padding (link to my comment above).

Best,

-          Tolga

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Sunday, November 18, 2012 4:45 AM
To: Mike Jones
Cc: IRTF CFRG; [email-masked]<mailto:[email-masked]>
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

Russ

                                                            -- Mike

Hi,

Thanks,

David

Cfrg mailing list

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Tue, 20 Nov 2012 20:53:21 +0000

Hi Tolga,

Thanks for the comments, more inline:

From: Tolga Acar <[email-masked]<mailto:[email-masked]>>
Date: Sunday, November 18, 2012 1:44 PM
To: 'Russ Housley' <[email-masked]<mailto:[email-masked]>>, 'Mike Jones' <[email-masked]<mailto:[email-masked]>>
Cc: 'IRTF CFRG' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

·         Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is clear this is not new, but a reuse of an existing padding scheme.

It makes sense to add a citation, but in Section 4 (Rationale), where PEM and PKCS padding are already mentioned.   The right citation seems to be to add these non-normative references:

   Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers  - RFC 1423
   PKCS #7: Cryptographic Message Syntax v1.5 – RFC 2315
   Cryptographic Message Syntax (CMS) - RFC 5652

·         Section 2.2, step 3. When MAC verification fails, the draft recommends halting the operation before CBC decryption. We have seen timing and error-code based attacks against TLS’ MAC-then-Encrypt scheme. I realize that the draft is prescribing E-t-M. Nonetheless, considering a potential flaw in HMAC-SHA2 series (I don’t know of any, but …), I’d suggest not halting the operation even after MAC check fails, but continuing on to CBC decryption, and then returning an error that doesn’t distinguish between a MAC and a decryption (pad check) error. Yes, this would consume more CPU cycles only to waste them *under an attack*, which is not necessarily bad.

Your suggestion aims to hide from an attacker whether or not the authentication check passed or failed, by removing the (significant) timing difference in whether decryption is performed or not.  I don't see what security advantage this provides.   In many scenarios an attacker could tell whether or not a message was accepted anyway, by observing that the receiver acted on that message.

·         Section 2.2, step 5. Unspecified error case of invalid padding (link to my comment above).

The draft does consider invalid padding, and takes a conservative in what you send, liberal in what you accept policy.   The sender is required to use PKCS/PEM style padding, but the receiver is only told to consider the final octet of the padding (which is the only octet that matters).   The Step you mention says:

                                                                           If the final octet has
       a value outside that range, then all of the data used in the
       processing of the message is zeroized and discarded, and the AEAD
       decryption operation returns an indication that it failed, and
       the operation halts.

This could be amended by saying that "If the padding string does not have the form described in Step 3, the message MAY be rejected".

I think that the liberal-in-what-you-accept policy is the best option here, but I could be convinced otherwise.   The citations for padding schemes mentioned earlier are silent on this issue.

David

Best,

-          Tolga

Russ

                                                            -- Mike

Hi,

Thanks,

David

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 21 Nov 2012 12:32:22 +1100

There are two risks:

1.       The CBC padding is processed before the MAC is verified

2.       The plaintext is used before the MAC is verified

The draft could make the CBC padding processing even safer by being even more lenient: only consider the least significant 4 bits of the last byte (ie modulo the block length). That is guaranteed to be in [0,15] so it always gives a valid padding length (0 means 16 bytes of padding). Such padding processing can never fail so it can never act as a padding oracle even if it is accidentally performed before the proper MAC integrity check.

Mind you, I would expect many implementations to use existing implementations for the padding that will not be changed to be lenient. Hence the Security Considerations should say that it is crucial that the MAC is verified before the CBC padding is processed.

If you operate in a streaming mode (ie you don’t want to buffer the whole ciphertext before outputting anything) then corrupted plaintext can be produced, and a MAC failure will only be reported later (or never, if the end of the ciphertext is never received). draft-mcgrew-aead-aes-cbc-hmac-sha2-01 “prevents” this by performing the MAC verification (step 3) before the decryption (step 4), but that ordering will be ignored by APIs that support streaming.

In Java, for instance, the Cipher class has an update(ByteBuffer input, ByteBuffer output) methods that can be called any number of times (outputting plaintext) before calling doFinal(...), at which point an exception is thrown if the integrity check fails. As an example, the BouncyCastle implementation of AES/GCM/NoPadding decryption returns plaintext from the update(...) calls; it does not buffer the plaintext until the integrity check in the doFinal(...) call.

The Security Considerations section hints at this issue by talking about a “single atomic operation”:
   There are security benefits to providing both confidentiality and
   authentication in a single atomic operation, as done in this note.
   This tight binding prevents subtle attacks such as the padding oracle
   attack.
Perhaps add that “while a streaming implementation of decryption can calculate some plaintext before all the ciphertext has been processed, the authenticity is not ensured until all the ciphertext has been processed”.

--
James Manger

                                                                           If the final octet has

David

---

From: Ben Laurie <[email-masked]>
Date: Wed, 21 Nov 2012 15:47:18 +0000

On 12 November 2012 20:25, Michael Jones <[email-masked]> wrote:
> 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
> 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.

Sorry for the drive-by comment, but this caught my eye...

The problem with this idea, though, is that authenticated encryption
does not require an "authentication tag" in general - it just requires
that decrypting a tampered or entirely invented ciphertext fails. So,
this seems like a short-sighted way to define it.

>
>
> 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
>
>
>
> To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> 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
>
>
> formed by
> <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
> _______________________________________________ jose mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/jose
>