Re: [TLS] About TLS 1.2 AEAD ciphers definition

Michael Gray <mickgray@au1.ibm.com> Thu, 27 May 2010 21:04 UTC

Return-Path: <mickgray@au1.ibm.com>
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 E89383A6980 for <tls@core3.amsl.com>; Thu, 27 May 2010 14:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 YsNx46B7j4dh for <tls@core3.amsl.com>; Thu, 27 May 2010 14:04:54 -0700 (PDT)
Received: from e23smtp05.au.ibm.com (e23smtp05.au.ibm.com [202.81.31.147]) by core3.amsl.com (Postfix) with ESMTP id 957383A68FD for <tls@ietf.org>; Thu, 27 May 2010 14:04:53 -0700 (PDT)
Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp05.au.ibm.com (8.14.3/8.13.1) with ESMTP id o4RL0isR014858 for <tls@ietf.org>; Fri, 28 May 2010 07:00:44 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o4RL4gOo1642588 for <tls@ietf.org>; Fri, 28 May 2010 07:04:42 +1000
Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o4RL4gRO025044 for <tls@ietf.org>; Fri, 28 May 2010 07:04:42 +1000
Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av04.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o4RL4gE9025041; Fri, 28 May 2010 07:04:42 +1000
In-Reply-To: <0CB6D965-5252-4112-A933-D3F390EB0F9A@iki.fi>
To: Juho Vähä-Herttua <juhovh@iki.fi>
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: <OF2A2EE598.0E4EB2D2-ON4A257730.00738D5A-4A257730.0073C5A3@au1.ibm.com>
From: Michael Gray <mickgray@au1.ibm.com>
Date: Fri, 28 May 2010 07:04:32 +1000
X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 28/05/2010 07:05:45
MIME-Version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Cc: Adam Langley <agl@imperialviolet.org>, 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 21:04:56 -0000

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

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

RFC 5289 Defines additional ECC GCM Cipher Suites

Mick

>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls