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

[Xuelei Fan <[e-mail]>]

>
> > > > The "supported_groups" extension defines the groups, while the
>> > > "key_share"
>> > > > extension defines both the groups and the key exchange
>> information.  Both
>> > > > extension has its own preferences for the supported named groups.
>> It's
>> > > > easy to get conflicted if the two preferences are not consistent.
>> The
>> > > > "key_share" extension contains the information of the supported
>> named
>> > > > groups.  So, the information can be used to indicate the client
>> supported
>> > > > named groups.  Maybe, for TLS 1.3, it is not necessary to use the
>> > > > "supported_groups" extension any more.
>> > >
>> > > The only way to be conflicted would be to send key share for group
>> not in
>> > > supported_groups. Sending supported_group for group not in key_shares
>> is
>> > > not a conflict[1].
>> > >
>> > The preferences may be not consistent, too.  For example, the
>> > supported_groups prefer ffdhe2048, but the key_share prefer ffdhe4096.
>> > Using two preferences would make the implementation inconsistent between
>> > vendors if no clearly specification about the preference of the two.
>>
>> Only supported_groups are perference-ordered. Key_shares is unordered,
>> with special exception for retry (the added group always goes last).
>>
>>
> In section 6.3.2.3:
>     client_shares
>          A list of offered KeyShareEntry values in descending order of
> client preference.
>
> I think, key_share is ordered too.  If considering both key_share and
> supported_groups together, looks like there are two options:
> 1. key_share defines the preferences and supported named groups, which is
> overlap with supported_groups. supported_groups is used for version
> down-negotiation purpose. Don't define supported_groups as mandatory any
> more.
>
> For this case, empty key_share vector can be used to indicate to request
> server choice shares.
>
> 2. key_share won't defines the preferences any more.  The named groups in
> key_share MUST exist in supported_groups extensions.  supported_groups is
> used to define the supported named groups and preference, and key_share is
> used to define the shares.  Both are mandatory.
>
> For this case, key_share can be omitted to indicate to request server
> choice shares.
>
>
Update: key_share can be omitted, or the client_shares vector can be empty to
indicate to request server choice shares.

Xuelei