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

[Ilari Liusvaara <[e-mail]>]

On Tue, Apr 28, 2015 at 10:53:13AM +0800, 武炳正(允中) wrote:
> 
> 
> > -----Original Message-----
> > From: Ilari Liusvaara [mailto:[e-mail]]
> > Sent: Tuesday, April 28, 2015 1:36 AM
> > To: 武炳正(允中)
> > Cc: [e-mail]
> > Subject: Re: [TLS] New Version Notification for
> > draft-bzwu-tls-ecdhe-keyshare-00.txt
> > 
> > On Mon, Apr 27, 2015 at 08:28:16PM +0800, 武炳正(允中) wrote:
> > >
> > > 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.
> > 
> > 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).
> 
> 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).

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

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

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