Re: [TLS] About TLS 1.2 AEAD ciphers definition

Juho Vähä-Herttua <juhovh@iki.fi> Thu, 27 May 2010 16:42 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 C574E3A6AFA for <tls@core3.amsl.com>; Thu, 27 May 2010 09:42:31 -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 5sUy3fNg+b0X for <tls@core3.amsl.com>; Thu, 27 May 2010 09:42:31 -0700 (PDT)
Received: from smtp-3.tky.hut.fi (smtp03.tky.fi [82.130.63.73]) by core3.amsl.com (Postfix) with SMTP id A119C3A6B24 for <tls@ietf.org>; Thu, 27 May 2010 09:42:29 -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 M2010052719421718985 ; Thu, 27 May 2010 19:42:17 +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 EBCAF1813D; Thu, 27 May 2010 19:42:17 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="iso-8859-1"
From: Juho Vähä-Herttua <juhovh@iki.fi>
In-Reply-To: <AANLkTilTmkQh6RzCX50L35Jt2IkQq8mzylIkQbnDY7gS@mail.gmail.com>
Date: Thu, 27 May 2010 19:42:18 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CB6D965-5252-4112-A933-D3F390EB0F9A@iki.fi>
References: <4BFE8FC5.4070509@iki.fi> <AANLkTilTmkQh6RzCX50L35Jt2IkQq8mzylIkQbnDY7gS@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 16:42:31 -0000

On 27.5.2010, at 19.04, Adam Langley wrote:
> On Thu, May 27, 2010 at 11:29 AM, Juho Vähä-Herttua <juhovh@iki.fi> 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 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.

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

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