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

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: <uri@ll.mit.edu>
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:foleyj@cisco.com]
Sent: Wednesday, August 21, 2013 03:08 PM
To: Wan-Teh Chang <wtc@google.com>
Cc: tls@ietf.org <tls@ietf.org>; Ryan Sleevi <sleevi@google.com>
Subject: Re: [TLS] draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD ciphers

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:
> 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
> .
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls