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

" 武炳正(允中) " <bingzheng.wbz@alibaba-inc.com> Tue, 28 April 2015 06:41 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 81CC71A0371 for <tls@ietfa.amsl.com>; Mon, 27 Apr 2015 23:41:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 G_Rd5xueQZaC for <tls@ietfa.amsl.com>; Mon, 27 Apr 2015 23:41:21 -0700 (PDT)
Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB321A0354 for <tls@ietf.org>; Mon, 27 Apr 2015 23:41:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1430203280; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=YLwdWtWafsX+vQafbplD8nQITEheE23R0510Vux8v5c=; b=NkcfTjYb/5gK0aX1to3mwd02gNl+fGXYo9ZO6SCLh35VP7I1VcfQthLH9WmDyWwEnANSI82SLxawwW89hcJWXWQn6ApDe6OFFomAK0RWrjhGuzYlQcyh01vyEjr1tn+jt4rHedSkzGuyCi4ozTNF30jGGUC7loSc2VxAwJGyezs=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03025; 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.158) by smtp.aliyun-inc.com(127.0.0.1); Tue, 28 Apr 2015 14:41:19 +0800
From: "武炳正(允中)" <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>
In-Reply-To: <20150428045440.GA7907@LK-Perkele-VII>
Date: Tue, 28 Apr 2015 14:41:18 +0800
Message-ID: <004c01d0817e$55580a80$00081f80$@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: AQINWeqB9X5GafILLq6JDjmchKPzTALdk8vxAddxaV4BIDadsAG0ZDKLnKvzU0A=
Content-Language: zh-cn
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/nT9aA9lS4Rf9zCAy_Jcy0AYF-rQ>
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: "武炳正(允中)" <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 06:41:22 -0000

> > Thanks for reminding.
> > Maybe a 'type' should be added in each ClientKeyShareOffer, to indicate
> different Diffie-Hellman exchange.
> > And change this extension's name from ECDHE-keyshare to DH-keyshare.
> 
> Well, there is a draft in pipeline (IETF LC complete, waiting for
> writeup) that assigns a range of group IDs for finite-field Diffie- Hellman (the
> TLS 1.3 group ids come from there).
> 
> Basically, the MSB of group ID being 0x01 means DHE (others are ECDHE).

Thanks again.
I find it in http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ .
So it seems that the 'type' is not need.
I only need to change the extension's name and description.


> > > 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).
> >
> > I tried to change as less as possible, to avoid unnecessary trouble, both in
> protocol or implementation.
> 
> Well, the difference between ECParameters and NamedCurve when
> non-named groups are disallowed is extra 0x03 prefix (to designate
> NamedCurve).

It's still easier to reuse tls1_check_curve() in OpenSSL if keeping the extra prefix.

> 
> 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".


expect for your recommendation
Bingzheng Wu