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

" 武炳正(允中) " <> Tue, 28 April 2015 11:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1EAFC1A8A1B for <>; Tue, 28 Apr 2015 04:42:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.5
X-Spam-Level: *
X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D2DWegojZ5uW for <>; Tue, 28 Apr 2015 04:42:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5559C1A89C7 for <>; Tue, 28 Apr 2015 04:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1430221358; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=O5MIEgLfJhW66SKj8yDK9I2tlozTwm/y5LdZECSPDDI=; b=LuEsU1enDtiAz4adC2KriA62SxSVgtv4OZOU4aJRAVn6aMPOf3OZo7radJu/df82hfrRMyMo0theM2jLmqHzylsDDpqgZ37tTv8UMO3Ts04s/h7scPrxt21AW57H4GpHKF774Ka/R2NPm1aMAXpSwXa94NbPfkFPikk2m8JbDng=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R201e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g08145;; PH=DS; RN=2; RT=2; SR=0;
Received: from ali074145n( ip: by; Tue, 28 Apr 2015 19:42:37 +0800
From: "武炳正(允中)" <>
To: 'Ilari Liusvaara' <>
References: <> <008e01d080e5$a2db6de0$e89249a0$> <20150427173533.GA910@LK-Perkele-VII> <001c01d0815e$783cbde0$68b639a0$> <20150428045440.GA7907@LK-Perkele-VII> <004c01d0817e$55580a80$00081f80$> <20150428081713.GA10271@LK-Perkele-VII>
In-Reply-To: <20150428081713.GA10271@LK-Perkele-VII>
Date: Tue, 28 Apr 2015 19:42:36 +0800
Message-ID: <006801d081a8$6c9c0f00$45d42d00$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQINWeqB9X5GafILLq6JDjmchKPzTALdk8vxAddxaV4BIDadsAG0ZDKLALAwPGEBMG+Ad5ydR36w
Content-Language: zh-cn
Archived-At: <>
Subject: Re: [TLS] New Version Notification for draft-bzwu-tls-ecdhe-keyshare-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "武炳正(允中)" <>
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: Tue, 28 Apr 2015 11:42:42 -0000

I understand that non-named curve is not safe.
But I think that, this extension aims to reduce the handshake's latency only.
The safety should be considered by the TLS protocol, but not this extension.

Whatever, I decide to remove support for non-named curve in the draft's new version,
because it's a litter troublesome to explain the extension_data format compatible with Negotiated FF Parameters.
While it's easier if remove non-named curve, and the extension_data becomes:

            struct {
                 NamedGroup    group_id;
                 select (typeof(group_id)) {
                     case FF:  ClientDiffieHellmanPublic;
                     case EC:  ECPoint;
                 } public_key;
            } ClientKeyShareOffer;

Besides, I have changed my draft's name into TLS client-keyshare extension.
So should I submit the new draft now?
I am not familiar with the workflow.

Thanks again for you valuable recommends.
Bingzheng Wu

> -----Original Message-----
> From: Ilari Liusvaara []
> Sent: Tuesday, April 28, 2015 4:17 PM
> To: 武炳正(允中)
> Cc:
> Subject: Re: [TLS] New Version Notification for
> draft-bzwu-tls-ecdhe-keyshare-00.txt
> On Tue, Apr 28, 2015 at 02:41:18PM +0800, 武炳正(允中) wrote:
> >
> > >
> > > Also, I consider using non-named groups to bring more security
> > > problems than it is worth (e.g. currently known ways to exploit THS for
> (EC)DHE rely on those).
> >
> > This extension aims to reduce the handshake's latency only.
> > I think it's more clear that this extension behaves the same as normal
> handshake, both for SSL library's developer and web server administrator.
> > If someone thinks non-named curve is not safe, he should find a way to
> > disable it for normal handshake; and this extension will not use non-named
> curves then.
> >
> > For example, a web server administrator may prefer the instructions
> > that "non-named curve is not safe. disable it in configure file",  than "
> non-named curve is not safe. but there is an extension which disable it
> automatically. However you still need to disable it in configure file".
> Actually, I think I figured out a nasty exploit.
> By choosing a suitable curve (assuming both server and client accept it), one
> can ECDL the server's exchange key and thus impersonate the server.
> Extended_master_secret will not save you.
> This exploit won't work with named groups (even without key order check). This
> is because client's premaster secret is too hard to compute.
> Also, TLS 1.3 server auth is different, so the same exploit won't work there
> either (even if it allowed non-named groups, which it doesn't).
> -Ilari