Re: [TLS] About TLS 1.2 AEAD ciphers definition

"Rob P Williams" <rwilliams@certicom.com> Fri, 28 May 2010 11:41 UTC

Return-Path: <rwilliams@certicom.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 3C7D73A69B8 for <tls@core3.amsl.com>; Fri, 28 May 2010 04:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Level:
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 ge7w5PedeEeI for <tls@core3.amsl.com>; Fri, 28 May 2010 04:41:34 -0700 (PDT)
Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 2E62E3A6781 for <tls@ietf.org>; Fri, 28 May 2010 04:41:33 -0700 (PDT)
X-AuditID: 0a666446-b7becae00000701c-ad-4bffabe21ee5
Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 92.75.28700.2EBAFFB4; Fri, 28 May 2010 07:41:22 -0400 (EDT)
Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 May 2010 07:41:23 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
Date: Fri, 28 May 2010 07:41:22 -0400
Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC405F1BE9F@XCH57YKF.rim.net>
In-Reply-To: <OF2A2EE598.0E4EB2D2-ON4A257730.00738D5A-4A257730.0073C5A3@au1.ibm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] About TLS 1.2 AEAD ciphers definition
Thread-Index: Acr94D7GZ2EmhlSGSKi5zxjpa0zuOQAej0vg
References: <0CB6D965-5252-4112-A933-D3F390EB0F9A@iki.fi> <OF2A2EE598.0E4EB2D2-ON4A257730.00738D5A-4A257730.0073C5A3@au1.ibm.com>
From: "Rob P Williams" <rwilliams@certicom.com>
To: "Michael Gray" <mickgray@au1.ibm.com>, =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= <juhovh@iki.fi>
X-OriginalArrivalTime: 28 May 2010 11:41:23.0127 (UTC) FILETIME=[B2A6D470:01CAFE5A]
X-Brightmail-Tracker: AAAAAQAAAZE=
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: Fri, 28 May 2010 11:41:35 -0000

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

> 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

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.