[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