Re: [TLS] Keyshare extension spec

[Dave Garrett <[e-mail]>]

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