Re: [TLS] WGLC for draft-ietf-tls-ecdhe-psk-01
badra@isima.fr Tue, 03 June 2008 18:25 UTC
Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3BEE3A6A68; Tue, 3 Jun 2008 11:25:10 -0700 (PDT)
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 D9EED3A6A60 for <tls@core3.amsl.com>; Tue, 3 Jun 2008 11:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.151
X-Spam-Level:
X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 0+KX191OPzK2 for <tls@core3.amsl.com>; Tue, 3 Jun 2008 11:25:09 -0700 (PDT)
Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id B060D3A6832 for <tls@ietf.org>; Tue, 3 Jun 2008 11:25:08 -0700 (PDT)
Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m53JLcJU377050; Tue, 3 Jun 2008 20:21:40 +0100
Received: from 78.113.163.124 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 3 Jun 2008 20:24:44 +0200 (CEST)
Message-ID: <52684.78.113.163.124.1212517484.squirrel@www.isima.fr>
Date: Tue, 03 Jun 2008 20:24:44 +0200
From: badra@isima.fr
To: tls@ietf.org
User-Agent: SquirrelMail/1.4.2
MIME-Version: 1.0
X-Priority: 3
Importance: Normal
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 03 Jun 2008 20:21:41 +0100 (WEST)
Cc: ah@tr-sys.de
Subject: Re: [TLS] WGLC for draft-ietf-tls-ecdhe-psk-01
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-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="utf-8"
Content-Transfer-Encoding: base64
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org
Dear all, In my turn, I propose (ala Pasi style) the following briefing of my proposal for addressing the WGLC comments for draft-ietf-tls-ecdhe-psk-01 (point 1), and of (point 2) the new ciphersuites (with SHAnnn and AES-GCM available at http://www.ietf.org/mail-archive/web/tls/current/msg02687.html Please don't hesitate to send your comments. 1. comments 1.1. <Alfre Haenes> > To accomodate the expected state of the TLS specifications upon > the desired publication of this draft as an RFC, I recommend to > perform the following additions/changes to this draft before > forwarding it to the IESG: > > - add an applicability statement for TLS revisions If the cipher suite discussed at the mailing list [1], will not be added, the following "Applicability Statement" sub-section will be added to the introduction: "The ciphersuites defined in this document can be negotiated, whatever the negociated TLS version." > - demote [RFC4346] to Informative, RFC4346 is used as reference only in Security Considerations section. Action: I will remove it. > - add new Normative Ref. to RFC 5246, and OK > - replace most uses of [RFC4346] by the pointer to the latter > (keep ref. [RFC4346] for text specific to TLS 1.1) OK 1.2. <Pasi Eronen> > The document is simple and looks good. I have one editorial > suggestion to improve clarity: > > In Section 2, the premaster secret involves two different secrets that > are shared between the peers. To be totally clear which is meant at > what time, it could be rephrased something like this: > > The premaster secret is formed as follows. First, perform the ECDH > computation as described in Section 5.10 of [RFC4492]. Let Z be the > octet string produced by this computation. Next, concatenate a > uint16 containing the length of Z (in octets), Z itself, a uint16 > containing the length of the PSK (in octets), and the PSK itself. > > This corresponds to the general structure for the premaster secrets > (see Note 1 in Section 2 of [RFC4279]), with "other_secret" > containing Z. OK, I will update the text. 2. The new ciphersuites ---------------------------- The proposed ciphersuites are discussed at http://www.ietf.org/mail-archive/web/tls/current/msg02687.html It seems that Eric doesn’t support adding those ciphersuites to the document nor to a seperate one. Pasi and Uri think that those may be added, if required, but to the same document. Please don't hesitate to say your opinion regarding this point. Alternatively, I kindly ask the co-Chairs to give the final decision in order to submit an updated version. Thank you. Best regards, Badra _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls