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

[Eric Rescorla <[e-mail]>]

On Thu, Nov 26, 2015 at 4:59 PM, Xuelei Fan <[e-mail]> wrote:

> If empty key_share vector is used to indicate to request a server choice,
>

That's not what it means. It means "I have no idea what your preferences
are, so tell
me which of the groups I support you prefer". Thus, you still need
supported_groups
to indicate the groups you support.

-Ekr



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