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

" 武炳正(允中) " <bingzheng.wbz@alibaba-inc.com> Tue, 28 April 2015 11:42 UTC

Return-Path: <bingzheng.wbz@alibaba-inc.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAFC1A8A1B for <tls@ietfa.amsl.com>; Tue, 28 Apr 2015 04:42:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2DWegojZ5uW for <tls@ietfa.amsl.com>; Tue, 28 Apr 2015 04:42:41 -0700 (PDT)
Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5559C1A89C7 for <tls@ietf.org>; Tue, 28 Apr 2015 04:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; 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; MF=bingzheng.wbz@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0;
Received: from ali074145n(mailfrom:bingzheng.wbz@alibaba-inc.com ip:42.120.74.180) by smtp.aliyun-inc.com(127.0.0.1); Tue, 28 Apr 2015 19:42:37 +0800
From: "=?GBK?B?zuSx/tX9KNTK1tAp?=" <bingzheng.wbz@alibaba-inc.com>
To: "'Ilari Liusvaara'" <ilari.liusvaara@elisanet.fi>
References: <20150427023926.28938.22369.idtracker@ietfa.amsl.com> <008e01d080e5$a2db6de0$e89249a0$@alibaba-inc.com> <20150427173533.GA910@LK-Perkele-VII> <001c01d0815e$783cbde0$68b639a0$@alibaba-inc.com> <20150428045440.GA7907@LK-Perkele-VII> <004c01d0817e$55580a80$00081f80$@alibaba-inc.com> <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$@alibaba-inc.com>
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: <http://mailarchive.ietf.org/arch/msg/tls/_hCmOPl1CNsc7tQwatXf-JySGVk>
Cc: tls@ietf.org
Subject: Re: [TLS] New Version Notification for draft-bzwu-tls-ecdhe-keyshare-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: =?GBK?B?zuSx/tX9KNTK1tAp?= <bingzheng.wbz@alibaba-inc.com>
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/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
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 [mailto:ilari.liusvaara@elisanet.fi]
> Sent: Tuesday, April 28, 2015 4:17 PM
> To: 武炳正(允中)
> Cc: tls@ietf.org
> 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