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

From: "武炳正(允中)" <[email-masked]>
Date: Mon, 27 Apr 2015 20:28:16 +0800

Hi All,

A new TLS extension draft has been posted to IETF repository

https://datatracker.ietf.org/doc/draft-bzwu-tls-ecdhe-keyshare/

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.

Thanks and best regards,
Bingzheng Wu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, April 27, 2015 10:39 AM
To: 武炳正(允中); 武炳正(允中)
Subject: New Version Notification for draft-bzwu-tls-ecdhe-keyshare-00.txt

A new version of I-D, draft-bzwu-tls-ecdhe-keyshare-00.txt
has been successfully submitted by Bingzheng Wu and posted to the IETF repository.

Name:		draft-bzwu-tls-ecdhe-keyshare
Revision:	00
Title:		Transport Layer Security (TLS) ECDHE Keyshare Extension
Document date:	2015-04-24
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-bzwu-tls-ecdhe-keyshare-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bzwu-tls-ecdhe-keyshare/
Htmlized:       http://tools.ietf.org/html/draft-bzwu-tls-ecdhe-keyshare-00

Abstract:
   This document defines an extension that allows a TLS client to carry
   Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) keyshare in
   ClientHello message, so as to reduce the full handshake latency of
   one network round-trip times (RTT).

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 27 Apr 2015 20:35:33 +0300

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

-Ilari

---

From: "武炳正(允中)" <[email-masked]>
Date: Tue, 28 Apr 2015 10:53:13 +0800

> From: Ilari Liusvaara [mailto:[email-masked]]
> Sent: Tuesday, April 28, 2015 1:36 AM
> To: 武炳正(允中)
> Cc: [email-masked]
> Subject: Re: [TLS] New Version Notification for
> draft-bzwu-tls-ecdhe-keyshare-00.txt
> 
> > This extension allows a TLS client to carry ECDHE keyshare in ClientHello
> message, so as to reduce the full handshake latency of 1RTT.
> >
> > 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).

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.

> 
> (The value list seems to be out-of-sync with ffdhe draft, which also has 6k).
> 
> I consider supporting arbitrary curves here a bad idea. Why not just use values
> out of EC Named Curve Registry (16-bit)?
> 

I tried to change as less as possible, to avoid unnecessary trouble, both in protocol or implementation.

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

I think so too.
I will add this in the draft after reading this extension carefully.
> (Let's not get into working around THS by key checks).

Thanks for your comments again
Bingzheng Wu

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 28 Apr 2015 07:54:40 +0300

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

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

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

> I will add this in the draft after reading this extension carefully.

Basically, the point needs to be after ServerKeyExchange (security) but
before ChangeCipherSpec (possible to implement).

(Without extensions, there is only one such point, but certain
extensions can add extra messages).

-Ilari

---

From: "武炳正(允中)" <[email-masked]>
Date: Tue, 28 Apr 2015 14:41:18 +0800

> 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)?
> > >
> 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

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 28 Apr 2015 11:17:13 +0300

>  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

---

From: "武炳正(允中)" <[email-masked]>
Date: Tue, 28 Apr 2015 19:42:36 +0800

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

> Sent: Tuesday, April 28, 2015 4:17 PM
> To: 武炳正(允中)
> Cc: [email-masked]
> > > 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).
> >
> > 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".
> 
> 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