On Thu, Nov 26, 2015 at 09:52:37PM +0800, Xuelei Fan wrote: > Hi, > > Per the latest draft of TLS 1.3, both "supported_groups" and "key_share" > extensions are REQUIRED for DHE or ECDHE cipher suites (Section 8.2). Both > extension need to provide the supported named groups in preference order. > Looks like the functions are overlapped. I was wondering, it may be nice > to obsolete the "supported_groups" extension, and use "key_share" extension > for both the supported named groups and the key exchange information for > each group.
This wouldn't work if one had to downnegotiate TLS 1.2. That is going to happen A LOT. Also, one can support curve, but not prefer to send share on it (the server can call for it, at cost of extra RTT). Plus, some of the curves are of special purpose and won't ever have shares. Also, IIRC, if client has no shares, it omits key_share. If server wants FS cipher suite, it then has to signal retry. > 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]. [1] In fact, I expect many clients to send shares for P-256 and X25519, plus offer P-384 and X448 (without shares unless requested). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
