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

[Xuelei Fan <[e-mail]>]

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 <[e-mail]> wrote:

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