Re: [TLS] New Version Notification for draft-bzwu-tls-ecdhe-keyshare-00.txt

Ilari Liusvaara <> Mon, 27 April 2015 17:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9677C1A903F for <>; Mon, 27 Apr 2015 10:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q2oF0DCBRXgv for <>; Mon, 27 Apr 2015 10:35:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 969DA1A902B for <>; Mon, 27 Apr 2015 10:35:36 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id C00C81887F0; Mon, 27 Apr 2015 20:35:33 +0300 (EEST)
Date: Mon, 27 Apr 2015 20:35:33 +0300
From: Ilari Liusvaara <>
To: "武炳正(允中)" <>
Message-ID: <20150427173533.GA910@LK-Perkele-VII>
References: <> <008e01d080e5$a2db6de0$e89249a0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <008e01d080e5$a2db6de0$e89249a0$>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
Archived-At: <>
Subject: Re: [TLS] New Version Notification for draft-bzwu-tls-ecdhe-keyshare-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Apr 2015 17:35:38 -0000

On Mon, Apr 27, 2015 at 08:28:16PM +0800, 武炳正(允中) wrote:
> This extension allows a TLS client to carry ECDHE keyshare in ClientHello message, so as to reduce the full handshake latency of 1RTT.
> Please kindly review it. Any comments are welcomed.

Taking a quick look (not considering if this a good idea or not):

> In fact the new version, TLS verion 1.3
> [draft] which works in progress, supports only ECDHE for key
> exchange.

This is just wrong. In TLS 1.3 editor's copy and in latest draft,
non-ECC DHE is supported (2k, 3k, 4k and 8k).

(The value list seems to be out-of-sync with ffdhe draft, which
also has 6k).

> ECParameters    curve_params;

I consider supporting arbitrary curves here a bad idea. Why
not just use values out of EC Named Curve Registry (16-bit)?

(That's the way TLS 1.3 does it).

> So I have not find any security problem about this extension
> yet.

Another problem:

Defintion of extended_master_secret (security fix!) refers
to ClientKeyExchange. The relevant part would have to be
redefined (I guess taking session_hash after
ServerKeyExchange would work).

(Let's not get into working around THS by key checks).