Re: [TLS] About TLS 1.2 AEAD ciphers definition

Juho Vähä-Herttua <juhovh@iki.fi> Thu, 27 May 2010 17:56 UTC

Return-Path: <juhovh@iki.fi>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8400C3A6783 for <tls@core3.amsl.com>; Thu, 27 May 2010 10:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Level:
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v4nNnvfpDAN for <tls@core3.amsl.com>; Thu, 27 May 2010 10:56:52 -0700 (PDT)
Received: from smtp-3.tky.hut.fi (smtp03.tky.fi [82.130.63.73]) by core3.amsl.com (Postfix) with SMTP id 757D73A693B for <tls@ietf.org>; Thu, 27 May 2010 10:56:52 -0700 (PDT)
Received: from smtp.vaha-herttua.fi ([82.130.46.36]) by smtp-3.tky.hut.fi (SMSSMTP 4.1.9.35) with SMTP id M2010052720564024752 ; Thu, 27 May 2010 20:56:40 +0300
Received: from vagabond.lan (qer2.kyla.fi [82.130.46.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.vaha-herttua.fi (Postfix) with ESMTPSA id 449591810A; Thu, 27 May 2010 20:56:41 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= <juhovh@iki.fi>
In-Reply-To: <AANLkTink409Nw256N_804EJEIO3LOh4Ozj9P1WgpjmIB@mail.gmail.com>
Date: Thu, 27 May 2010 20:56:41 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <2194F326-567F-4704-A37A-90F9A8EB3C2D@iki.fi>
References: <4BFE8FC5.4070509@iki.fi> <AANLkTilTmkQh6RzCX50L35Jt2IkQq8mzylIkQbnDY7gS@mail.gmail.com> <0CB6D965-5252-4112-A933-D3F390EB0F9A@iki.fi> <AANLkTink409Nw256N_804EJEIO3LOh4Ozj9P1WgpjmIB@mail.gmail.com>
To: Adam Langley <agl@imperialviolet.org>
X-Mailer: Apple Mail (2.1078)
Cc: tls@ietf.org
Subject: Re: [TLS] About TLS 1.2 AEAD ciphers definition
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 17:56:53 -0000

On 27.5.2010, at 20.11, Adam Langley wrote:
> On Thu, May 27, 2010 at 12:42 PM, Juho Vähä-Herttua <juhovh@iki.fi> 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