On Thu, Nov 26, 2015 at 11:37:12PM +0800, Xuelei Fan wrote: > > 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.
Given the slowness even _security_ _fix_ extensions get deployed, planning any sort of transition is not IMO a good idea. > > 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? Yes, generating key exchanges can be expensive (even if it is cheaper for each group then performing the actual key exchange). Especially for P-384, P-521 and larger DH groups. Also, the shares can get large if many are sent. "Xmas tree" client keyshare is 3384 bytes by quick calculation (whereas the one containing P-256 and X25519 is just 109). That's many times the rest of the ClientHello, and might already cause problems. Better plan might be to guess, as the cost of wrong guess is mostly just 1 RTT. > > 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. The current grammar does not allow empty value, so it is free. But considering one needs supported_groups for backward compat., one can just rely on that to signal that group is supported but no share is given. > > > 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 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. > 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. I think two extensions are needed for backward compatiblity: One needs to use supported_groups, but one can't extend it, so two extension it is. TLS 1.3 (without 0-RTT) is supposed to be possible to downnegotiate at least to TLS 1.2. > > > 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). > > [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. Basically, with some groups, sending on request is the only workable option, given how slow or large some shares are. Now, if PQ key exchanges were added, things would get worse, because those methods tend to either have large keys or slow key exchange/ generation. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
