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

[John Foley <[e-mail]>]

Hi David,

CTS is a great idea.  This looks like it could be used to solve the
problem.  We could certainly go this route.  However, thinking through
the implementation details, is CTS widely deployed?  I'm fairly certain
OpenSSL doesn't support CTS.  Is there an RFC that defines AES-CBC-CTS
mode?  If not, would we need to propose an IETF draft for this new
mode?  Thinking through both the standards process and implementation
process, it might looking something like:

1) Author new draft for AES-CBC-CTS mode that coincides with NIST 800-38A?
2) Revise [draft-mcgrew-aead-aes-cbc-hmac-sha2] to include AES-CBC-CTS mode.
3) Register new AES-CBC-CTS TLS cipher suites with IANA.

And moving on to implementation (e.g. OpenSSL, GNUTLS, etc.)...
4) Implement block cipher mode AES-CBC-CTS
5) Add support for the new cipher suites to TLS stack

To second your final comment, what gain would come from this new
AES-CBC-CTS mode for TLS?  Does it achieve anything that GCM mode
doesn't provide today?  It's not clear to me this new mode would be
providing additional value.  Is this merely continued expansion of the
ever increasing list of TLS cipher suites?

John


On 08/27/2013 05:27 PM, David McGrew wrote:
> Hi John,
>
> On Wed, 2013-08-21 at 15:08 -0400, John Foley wrote:
>> 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.
> 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
>
>>
>>
>>
>> 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
>>> .
>>>
>
> .
>