Thanks for the quick feedback. You answered some questions puzzled me for a while.
On Thu, Nov 26, 2015 at 10:26 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > 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. > > I think, "supported_groups" extension still can be sent for TLS 1.2, but can be ignored for TLS 1.3. And "key_share" extension can be extended to support TLS 1.2 and previous versions. > Also, one can support curve, but not prefer to send share on it (the > server can call for it, at cost of extra RTT). > > The scenarios may be not effective because of the extra RTT. As if the client want to negotiate the curve, it may be more effective to provide the key information in the beginning. Or, maybe the generation of the key exchange information is more expensive? > Plus, some of the curves are of special purpose and won't ever have > shares. > > I missed this point. Is it possible to update the shares to tolerate the special purpose? For example, allowing empty shares. > Also, IIRC, if client has no shares, it omits key_share. If server wants > FS cipher suite, it then has to signal retry. > > That's may be the point I missed, too. Where and when the shares come from? Looks like there are two cases: 1. client generate the shares and wrap them in the initial ClientHello message. 2. client omits the key_share, but still request for (EC)DHE cipher suites. If server want to negotiate (EC)DHE cipher suite, need an extra RTT. Client generate the shares on server request. I think the cases answer my confusing of the two extensions. Suppose, if the shares can be optional, maybe it is easier to use key_share only. If client has no shares, using key_share with no shares (function as supported_groups); if client has shares, using key_share with shares. > > 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. > [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). > > > I like this scenarios more. It might be more clear if TLS 1.3 support this scenarios, but not the scenarios that sending shares before requested. For the TLS vendors, client implementation may only consider one option. While a server implementation need to consider both, the effort doubles. Thanks, Xuelei > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
