On Friday, December 11, 2015 08:13:05 pm Christian Huitema wrote: > I am looking at the specification of the key share extension, section 6.3.2.3 > of the 1.3 draft. I think that the behavior is somewhat underspecified. The > spec says: > > ...Clients MAY omit this extension from the ClientHello, and in response to > this, servers MUST send a HelloRetryRequest requesting use of one of the > groups the client offered support for in its "supported_groups" extension. If > no common supported group is available, the server MUST produce a fatal > "handshake_failure" alert.
There's some cruft in the current draft leftover from ekr and I waffling back/forth on whether to omit or send an empty extension when requesting server selection. (was pointed out on this list by someone else a couple weeks ago) We eventually decided on empty. I have a PR pending review that fixes the merge mistakes and clarifies some bits. https://github.com/tlswg/tls13-spec/pull/349/files > I am concerned with the hypothetical case in which the client sends a list of > groups in the "named group" extension but only sends keys for a subset of > these groups in the "key share" extension. For example, a client might > propose secp256r1 and secp384r1 in the named group extension, leading the > server to select secp256r1, but only provide a key for secp384r1 in the key > share extension. The server has two options: > > * produce a fatal handshake failure alert, because no common supported group > is available, > * or, send a HelloRetryRequest requesting use of one of the groups the client > offered support for, secp256r1 in the example. > > Which is the correct interpretation? Is one of these behaviors preferred, or > are both available? The latter: HelloRetryRequest is the required response. (See also the PR noted above.) The retry mechanism essentially allows key shares to be provided on-demand. Servers selecting a group that is supported, but not provided, request it via the HelloRetryRequest. > Also, what is supposed to happen if the client sends an empty Key Share > extension? With the pending changes this is the explicit HelloRetryRequest request case. Lack of the extension when offering suites requiring it a fatal "missing_extension" alert. (switching to supplying an empty extension when requesting a retry makes this simpler) > Or, if its listed key share extensions list keys for groups that are not > indicated in the "named group" extension? I have a "MUST NOT" for doing that in the pending PR. In order to be thorough, I've just amended it with a specific fatal alert to throw. Though other mechanisms should catch an attempt to inject a bogus key share, implementations not checking for and erroring on unsupported keys here sounds like a recipe for badness. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
