Re: [TLS] About TLS 1.2 AEAD ciphers definition

[Juho Vähä-Herttua <[e-mail]>]

On 27.5.2010, at 20.11, Adam Langley wrote:
> On Thu, May 27, 2010 at 12:42 PM, Juho Vähä-Herttua <[e-mail]> wrote:
>> 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.
> 
> 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.

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.

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

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