[TLS] Comments about rsa-aes-gcm and ecc-new-mac
<Pasi.Eronen@nokia.com> Tue, 04 March 2008 08:45 UTC
Return-Path: <tls-bounces@ietf.org>
X-Original-To: ietfarch-tls-archive@core3.amsl.com
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06EE028C504; Tue, 4 Mar 2008 00:45:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
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 hp5YEWSCRYYX; Tue, 4 Mar 2008 00:45:13 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD5B3A6E5D; Tue, 4 Mar 2008 00:45:12 -0800 (PST)
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 53A0A3A68A0 for <tls@core3.amsl.com>; Tue, 4 Mar 2008 00:45:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 3sdHmjE+3p+q for <tls@core3.amsl.com>; Tue, 4 Mar 2008 00:45:02 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C5D3B28C48C for <tls@ietf.org>; Tue, 4 Mar 2008 00:45:01 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m248iks9022541 for <tls@ietf.org>; Tue, 4 Mar 2008 10:44:50 +0200
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Mar 2008 10:44:49 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Mar 2008 10:44:49 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 04 Mar 2008 10:44:49 +0200
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2405578CA7@esebe105.NOE.Nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments about rsa-aes-gcm and ecc-new-mac
Thread-Index: Ach91AGvrOqD+EUdRNWJKHj0TEZZsg==
From: Pasi.Eronen@nokia.com
To: tls@ietf.org
X-OriginalArrivalTime: 04 Mar 2008 08:44:49.0303 (UTC) FILETIME=[01935270:01C87DD4]
X-Nokia-AV: Clean
Subject: [TLS] Comments about rsa-aes-gcm and ecc-new-mac
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org
<not wearing any hats> 1) The definition of how AES_128_GCM and AES_256_GCM work in TLS really should be in one document only, with the other one having just a reference. (Since ecc-new-mac is Informational, the text would need to go in rsa-aes-gcm.) If in the future we define other combinations, like TLS_PSK_WITH_ AES_128_GCM_SHA256, it wouldn't make much sense to repeat the nonce generation details and related security considerations in that document -- we'd just say "AES_128_GCM and its security considerations are in [X]". For the same reason, it doesn't make much sense to repeat it here either (and the two documents currently don't have same text anyway -- e.g. rsa-aes-gcm has more text about counter reuse in security considerations). 2) Both documents mention DTLS -- but none of these ciphersuites can be actually used with RFC 4347 (since they can't be used with TLS 1.1). 3) Section 1 of rsa-aes-gcm draft would benefit from some rephrasing (e.g. include similar text as the abstract contains; split the "why GCM is good" marketing text to separate paragraph; expand CAPWAP, etc.) 4) The nonce generation text in Section 3 of rsa-aes-gcm could benefit from some rephrasing and rearrangement. Here's my my proposal (trying to be a purely editorial rearrangement of current text): The "nonce" SHALL be 12 bytes long, and it consists of two parts as follows: (this is an example of "partially implicit" nonce; see Section 3.2.1 of [RFC5116]) struct { opaque salt[4]; opaque nonce_explicit[8]; } GCMNonce; The salt is the "implicit" part of the nonce and is not sent in packets. Instead, the salt is generated as part of the handshake process: it is either the client_write_IV (when the client is sending) or the server_write_IV (when the server is sending). The salt length (SecurityParameters.fixed_iv_length) is 4 octets. The "nonce_explicit" part is chosen by the sender and is carried in each TLS record, in the GenericAEADCipher.nonce_explicit field. The explicit part length (SecurityParameters.record_iv_length) is 8 octets. Each value of the nonce_explicit MUST be ... 5) rsa-aes-gcm reference [GCM] has old title and date. Best regards, Pasi _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- [TLS] Comments about rsa-aes-gcm and ecc-new-mac Pasi.Eronen