Subject: [TLS] draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD ciphers

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 21 Aug 2013 10:49:55 -0700

While reviewing the NSS patch for the AES-GCM TLS cipher suites, my
colleague Ryan Sleevi noticed that the AEAD algorithms defined in
draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD
ciphers. The problem is how TLS 1.2 specifies the additional
authenticated data for AEAD ciphers:

RFC 5246 Section 6.2.3.3 says:

   The plaintext is the TLSCompressed.fragment.

   The additional authenticated data, which we denote as
   additional_data, is defined as follows:

      additional_data = seq_num + TLSCompressed.type +
                        TLSCompressed.version + TLSCompressed.length;

   where "+" denotes concatenation.

So additional_data includes the length of the plaintext
(TLSCompressed.length). But a TLS 1.2 record only gives us the length
of the AEAD ciphertext. So the recipient needs to calculate the
plaintext's length using only the ciphertext.

This is difficult to do with the AEAD algorithms in
draft-mcgrew-aead-aes-cbc-hmac-sha2 because the amount of padding, and
therefore the plaintext length, is only known after CBC decryption.

Is this a known problem with TLS 1.2 AEAD ciphers?

Wan-Teh Chang

---

From: Adam Langley <[email-masked]>
Date: Wed, 21 Aug 2013 14:02:22 -0400

> Is this a known problem with TLS 1.2 AEAD ciphers?

I hit the same issue while planning to move OpenSSL's TLS CBC decoding
into EVP (a lower-layer of OpenSSL). I couldn't figure out a way
around it and gave up.

Cheers

AGL

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 21 Aug 2013 14:56:56 -0400

>into EVP (a lower-layer of OpenSSL). I couldn't figure out a way

I personally would just use AES-GCM and be content. There's no reason
(AFAIK :) to use CBC-HMAC-SHA any more. ;)

---

From: John Foley <[email-masked]>
Date: Wed, 21 Aug 2013 15:08:27 -0400

Agreed, RFC 5246 section 6.2.3.3 is written for AEAD ciphers that grow
the payload by a fixed length. [draft-mcgrew-aead-aes-cbc-hmac-sha2]
grows the payload by a variable length because CBC mode is used.  The
only way to use this with TLS 1.2 would be to violate the spec by
increasing the TLSCompressed.length by the pad value prior to
encrypting.  Then when decrypting we would have the appropriate value
for the additional data input.

It seems that [draft-mcgrew-aead-aes-cbc-hmac-sha2] needs to include a
section to revise RFC 5246, or another draft is required that revises
5246 to allow use of variable pad length AEAD ciphers.

On 08/21/2013 01:49 PM, Wan-Teh Chang wrote:
> .

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 21 Aug 2013 17:21:41 -0400

How many AEAD modes do we care to have?

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <[email-masked]>
Lexington, MA  02420-9185       

Web:  http://www.ll.mit.edu/CST/

MIT LL Root CA: 

 <https://www.ll.mit.edu/labcertificateauthority.html>

DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: John Foley [mailto:[email-masked]]
Sent: Wednesday, August 21, 2013 03:08 PM
To: Wan-Teh Chang <[email-masked]>
Cc: [email-masked] <[email-masked]>; Ryan Sleevi <[email-masked]>
Subject: Re: [TLS] draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD ciphers

> Is this a known problem with TLS 1.2 AEAD ciphers?

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Thu, 22 Aug 2013 09:17:44 +0800

On Thursday, August 22, 2013, Adam Langley wrote:

> On Wed, Aug 21, 2013 at 1:49 PM, Wan-Teh Chang <[email-masked]<javascript:;>>
> wrote:

I came across this a few years ago and finally ended up just writing errata
2390, which simply removes the confusing notion of padding from the
specification, because padding didn't seem to be possible.

Personally I think the AEAD interface of TLS is broken, but people on this
list were not concerned at the time, because it is "only used for GCM
anyway". I can understand that, since fixing it now is not trivial.
Patching the specification in some other document easily leads to
confusion, especially when the original document states that padding should
be possible, and therefore the patch should not even be necessary.

Juho

---

From: David McGrew <[email-masked]>
Date: Tue, 27 Aug 2013 17:20:49 -0400

Hi Wan-Teh,

thanks to you and Ryan for identifying and raising this issue, more
inline:

> therefore the plaintext length, is only known after CBC decryption.

Yes, this is true.

Given the CBC decryption key, it is not hard to find the length of the
plaintext (and the final block can be decrypted as P_n = AES-DEC(K, C_n)
XOR C_{n-1} without decrypting any other blocks, if that is desired).
But it would be undesirable to use this technique, since we want the key
to "stay inside" the AEAD algorithm.  

RFC 5116 asks that each algorithm "provide a description relating the
length of the plaintext to that of the ciphertext."   What you have
found is that draft-mcgrew-aead-aes-cbc-hmac-sha2 provides a
relationship for finding the ciphertext length from the plaintext
length, but not the reverse, and it is impossible to find that reverse
relationship without the secret key.  

All of the AEAD algorithms in the registry (which are based on CCM, GCM,
and SIV) use counter-mode style encryption, and don't have this
problem.   

I have some thoughts on changes that can improve the situation, which
I'll send in reply to John's email.

thanks,

David

---

From: David McGrew <[email-masked]>
Date: Tue, 27 Aug 2013 17:27:02 -0400

Hi John,

> 5246 to allow use of variable pad length AEAD ciphers.

another alternative would be to define a CBC based ciphersuite that uses
Cipher Text Stealing [1].   Then the plaintext and ciphertext lengths
would be off by a constant, as with the other AEAD algorithms.  Now, the
existing padding method is used by the current draft because that method
is commonly implemented in CBC libraries (it dates back to early PKCS),
especially those used in JOSE.   But if it is desirable, we could define
a CBC algorithm that used CTS.   Since some JOSE adopters have already
implemented the current version of the draft, they may want to stick
with the current algorithm.  

David

P.S. - or we could stop using CBC, which is something that deserves
serious discussion.

[1]
http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp800-38A.pdf

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 28 Aug 2013 10:48:08 -0700

Hi David,

Thank you for your reply and suggestions.

Re: CTS: I agree with John that adding CTS would be opposite to the
reason for existence for draft-mcgrew-aead-aes-cbc-hmac-sha2 because
CTS is not widely deployed.

I am more interested in figuring out how TLS can use an AEAD algorithm
that obscures the plaintext length. Consider the additional_data in
TLS 1.2:

The plaintext length (TLSCompressed.length) is the problematic part.
Since the authentication tag of an AEAD algorithm should already cover
either the plaintext length or the ciphertext length, it seems that we
can safely remove TLSCompressed.version from additional_data. We can
consider making this change in TLS 1.3.

Wan-Teh Chang