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

[David McGrew <[e-mail]>]

Hi Wan-Teh,

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

On Wed, 2013-08-21 at 10:49 -0700, Wan-Teh Chang wrote:
> 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.

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

> 
> Is this a known problem with TLS 1.2 AEAD ciphers?
> 
> Wan-Teh Chang