Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3

[Eric Rescorla <[e-mail]>]

On Thu, Nov 26, 2015 at 3:36 PM, Dave Garrett <[e-mail]>
wrote:

> On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote:
> > On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett <[e-mail]>
> > wrote:
> > > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote:
> > > > I actually looked at the Editors's Copy. The description is a mess:
> It
> > > > seemingly first requires key_share extension, even for the first
> > > > ClientHello... Now, that extension can't be empty... And then
> proceeds
> > > > to say to omit it if client has no shares to send... Which looks like
> > > > it is mutually contradictionary.
> > >
> > > We went back and forth on whether to omit or require an empty
> extension.
> > > It looks like we have a mix of the two left in there that need fixing.
> (I
> > > think something got merged weird) Thanks for pointing this out.
> > >
> > > I think it might be easier if we just required the extension for all
> cases
> > > where (EC)DHE suites are offered, and have it empty to request a server
> > > choice, instead of an omitted extension.
> >
> > Yes, we should either have that or have empty be forbidden. It's a
> matter of taste
> > but on balance, let's go with "empty". If you want to submit a PR that
> cleans
> > this up, I'll merge that.
>
> ->  https://github.com/tlswg/tls13-spec/pull/349
>
> There's one last decision, though: does "empty" mean empty client_shares
> vector or empty "extension_data" to save 2 bytes? I think it's cleaner to
> just keep the same extension structure for all cases and have an empty
> shares vector, which is what I have in the current PR.


Empty vector seems dominant.

-Ekr


>
> Dave
>