If empty key_share vector is used to indicate to request a server choice, I think it is not necessary to have "supported_groups" extension as mandatory any more. key_share extension can be used for the supported named groups. "supported_groups" extension can be used for backward compatibility (if TLS 1.2 fade out in the future, need no "supported_groups" extension any more).
Or, if both are needed as mandatory, may be better to separate functions that "supported_groups" extension defines the supported named groups and preference, and key_share defines the shares only (no supported groups, no preference, the groups must be defined in "supported_groups" extension). Xuelei On Fri, Nov 27, 2015 at 7:47 AM, Eric Rescorla <[email protected]> wrote: > > > On Thu, Nov 26, 2015 at 3:36 PM, Dave Garrett <[email protected]> > wrote: > >> On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote: >> > On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett <[email protected]> >> > 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 >> > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
