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