Subject: [TLS] About TLS 1.2 AEAD ciphers definition

From: Juho Vähä-Herttua <[email-masked]>
Date: Thu, 27 May 2010 18:29:09 +0300

Hi,

I'm implementing TLS (including v1.2) and went through the 6.2.3.3. 
chapter of AEAD ciphers definition. The following puzzles me:

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

       AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext,
                                    additional_data)

       TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
                                             AEADEncrypted,
                                             additional_data

This seems to be strange in case of AEAD-Decrypt, because 
additional_data contains TLSCompressed information, which is not 
available before decryption. I started to trace it down and found out it 
was changed in draft-ietf-tls-rfc4346-bis-05 back in 2007. To find some 
reason for this change, I noticed the following email:

http://www.ietf.org/mail-archive/web/tls/current/msg01870.html

It seems to me that the change was made after this email and probably as 
a response to it. Before the change AEAD-Encrypt was using 
TLSCompressed.length and AEAD-Decrypt was using TLSCiphertext.length, 
which may be different if the AEAD cipher adds some own padding to it.

So I'm curious to know how is AEAD actually handled and how to find out 
the TLSCompressed.length when constructing additional_data for 
AEAD-Decrypt? I'm sure there are more experienced people here who can 
tell me the answer. Thank you in advance.

Juho

---

From: Adam Langley <[email-masked]>
Date: Thu, 27 May 2010 12:04:44 -0400

On Thu, May 27, 2010 at 11:29 AM, Juho Vähä-Herttua <[email-masked]> wrote:
> So I'm curious to know how is AEAD actually handled and how to find out the
> TLSCompressed.length when constructing additional_data for AEAD-Decrypt? I'm
> sure there are more experienced people here who can tell me the answer.
> Thank you in advance.

I believe that none of the currently defined AEAD ciphers introduce
padding, so it's pretty easy for the moment.

The use of TLSCompressed.length mirrors the behaviour of the CBC mode.
I can imagine an AEAD cipher where it would be nicer if the additional
data covered the TLSCiphertext.length and may it should be changed,
although it's all a little nebulous when we don't have an actual
example of an AEAD cipher which needs it.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Thu, 27 May 2010 19:42:18 +0300

> padding, so it's pretty easy for the moment.

The only currently defined AEAD ciphers seem to be AES_128_GCM and AES_256_GCM defined by RFC 5288. I'm a bit surprised that AES encryption doesn't introduce padding though, it might be just me misunderstanding the GCM process but I thought it still needs to pad the input data to match the block size, doesn't it? The TLSv1 explicit padding of CBC ciphers is not present in the AEAD ciphers at all. RFC 5288 doesn't define any kind of padding either, which makes me wonder how it is actually implemented... 

Also, if the TLSCompressed.length and TLSCiphertext.length are equal, how is it possible that the AEAD ciphers provide authentication? Shouldn't it at least add the Auth Tag to the message after encryption? Adding authentication without increasing the data length at all sounds a bit difficult. I'm actually more confused after this answer than I was before it.

> example of an AEAD cipher which needs it.

If the additional data covered the TLSCiphertext.length, it would be quite difficult to give it to AEAD-Encrypt, because the TLSCiphertext.length is not known before encryption just like TLSCompressed.length is not known before decryption. So I don't think it would solve anything either.

Sorry if my questions are stupid, but it's better to ask than do something incompatible. I would especially be interested in hearing from someone who has implemented the AES GCM mode cipher suites.

Juho

---

From: Adam Langley <[email-masked]>
Date: Thu, 27 May 2010 13:11:26 -0400

> Also, if the TLSCompressed.length and TLSCiphertext.length are equal, how is it possible that the AEAD ciphers provide authentication? Shouldn't it at least add the Auth Tag to the message after en…

Sorry, I meant that the ciphertext length is equal to the plaintext
length. You're correct that, in TLS speak, TLSCiphertext.length also
includes the MAC. But the MAC is a known length.

> The only currently defined AEAD ciphers seem to be AES_128_GCM and AES_256_GCM defined by RFC 5288. I'm a bit surprised that AES encryption doesn't introduce padding though, it might be just me misunderstanding the GCM process but I thought it still needs to pad the input data to match the block size, doesn't it?

GCM doesn't require padding since the encryption is a counter mode.

AGL

---

From: Joshua Davies <[email-masked]>
Date: Thu, 27 May 2010 12:12:40 -0500

On 05/27/2010 11:42 AM, Juho Vähä-Herttua wrote:
>> On Thu, May 27, 2010 at 11:29 AM, Juho Vähä-Herttua<[email-masked]>  wrote:
>>      
Aren't all AEAD ciphers derivatives of "COUNTER" mode?  My understanding 
of "COUNTER" mode was that it flipped the initialization vector around 
(encrypted the IV rather than the input block) so that no padding was 
ever necessary.

<http://twiki.dev.sabre.com/twiki/bin/view/Travelocity/TVLYArchitecture>

---

From: Martin Rex <[email-masked]>
Date: Thu, 27 May 2010 19:26:42 +0200 (MEST)

=?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= wrote:
> 
> The only currently defined AEAD ciphers seem to be AES_128_GCM and
> AES_256_GCM defined by RFC 5288. I'm a bit surprised that AES
> encryption doesn't introduce padding though, it might be just me
> misunderstanding the GCM process but I thought it still needs to pad
> the input data to match the block size, doesn't it?

Yes, that is likely a misunderstanding.

http://en.wikipedia.org/wiki/Counter_mode#Counter_.28CTR.29

Counter mode turns a block cipher into a generator of a (pseudo) random pad,
Essentially, the _application_data_ is encrypted by XORing it with
that (pseudo) random pad exactly like a stream cipher such as RC4 would
do it.

Only when the application data is encrypted with the block cipher function
it is necessary to pad the data up to the full block size, as with the more
traditional modes of operation for block ciphers such as CBC or ECB.

-Martin

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Thu, 27 May 2010 20:56:41 +0300

> includes the MAC. But the MAC is a known length.

Well, not quite equal to plaintext length either, since plaintext in TLS speak would equal to the decompressed original record. But it indeed includes the MAC, and also the IV/nonce and padding when relevant.

To conclude, in case of AEAD I should assume that it is using a non-padding cipher (like the CCM and GCM modes mentioned) and should also assume that TLSCiphertext.length is always exactly SecurityParameters.record_iv_length + TLSCompressed.length + SecurityParameters.mac_length. It does make sense, but is against the specification which says:

   The aead_output consists of the ciphertext output by the AEAD
   encryption operation.  The length will generally be larger than
   TLSCompressed.length, but by an amount that varies with the AEAD
   cipher.  Since the ciphers might incorporate padding, the amount of
   overhead could vary with different TLSCompressed.length values.

With this definition I find it quite hard to write a compatible implementation and would rather consider dropping at least the AEAD part from TLSv1.2 completely. Downside is that if most implementations decide to do the same, it will never be widely used.

> GCM doesn't require padding since the encryption is a counter mode.

True, leftover output bytes in counter mode can of course be dropped as irrelevant. This is already becoming more popular question to answer than the others, so nothing more about that. :) 

Juho

---

From: Michael Gray <[email-masked]>
Date: Fri, 28 May 2010 07:04:32 +1000

Juho Vähä-Herttua wrote on 28/05/2010 02:42:18 AM:

> the input data to match the block size, doesn't it? The TLSv1
> explicit padding of CBC ciphers is not present in the AEAD ciphers
> at all. RFC 5288 doesn't define any kind of padding either, which
> makes me wonder how it is actually implemented...

RFC 5289 Defines additional ECC GCM Cipher Suites

Mick

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

---

From: "Rob P Williams" <[email-masked]>
Date: Fri, 28 May 2010 07:41:22 -0400

Michael Gray wrote on Thursday, May 27, 2010 5:05 PM

> RFC 5289 Defines additional ECC GCM Cipher Suites

They are all still AES_128/256_GCM...

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Russ Housley <[email-masked]>
Date: Fri, 28 May 2010 10:13:51 -0400

>> misunderstanding the GCM process but I thought it still needs to
>> pad the input data to match the block size, doesn't it? The TLSv1

No, not all AEAD ciphers use counter mode.  However, all AEAD ciphers
that are used to protect the data stream in TLS at this moment make use
of counter mode for the encryption.

AES-CCM and AES-GCM both used counter mode for encryption, but they get
authentication in very different ways.

AES-Key-Wrap and AES-Key-Wrap-with-Pad are both AEAD ciphers, and they
do not use counter mode.

Russ