> > > > > 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
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
