Change:
6.3.2.3. <del> The "client_key_share" extension MUST be provided by the client if it offers any cipher suites that involve non-PSK (currently DHE or ECDHE) key exchange.  It contains the client's cryptographic parameters for zero or more key establishment methods.  [[OPEN ISSUE: Would it be better to omit it if it's empty?. </del> <ins> The "client_key_share" extension contains the client's cryptographic parameters for zero or more non-PSK key establishment methods (currently DHE or ECDHE). All clients MUST send a valid "client_key_share" extension when offering any DHE or ECDHE cipher suites.  Servers MUST NOT negotiate use of a DHE or ECDHE cipher suites unless the client supplies a (possibly empty) "client_key_share" extension.  If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert. (see mti-extensions) Servers MUST NOT send this extension.  TLS servers MUST support receiving this extension.  Clients receiving this extension MUST respond with an "unsupported_extension" alert and close the connection. [[OPEN ISSUE: Would it be better to omit it if it's empty?. </ins> https://github.com/tlswg/tls13-spec/issues/190]] %%% Key Exchange Messages struct { NamedGroup group; opaque

Discussion:
Modified extension requirements based on recent list discussion. It's a little verbose with repeated boilerplate, but it's clear no matter which section you read now. I've also moved the relevant requirements up top to a consistent place for each extension's section. The level of strictness here is now: If attempting to negotiate and the mandatory extension isn't available: MUST error If just detecting an invalid combination, but not actively negotiating: MAY error SNI is clearly listed as MUST support, servers MAY require, and SHOULD error if required The "unsupportedextension" alert is reworded more generally and put in as the consequence for violating the pre-existing "MUST NOT" send the client-only extensions from a server requirements. Also added some more, namely the fact that "clientkey_share" is clearly an error to be sent from a server.
NAME & NAME Please take a look when you get a chance. Are we all on the same page with this language? Anything that needs tweaking to focus on the above better? Edited to add: Also, do I need to cut out SNI again, or is this wording ok? It's not requiring it to be sent, just noting it must be supported, which was agreed to on list a while ago, and noting the existing case that servers MAY require it with a way to indicate it using the new error alert.
NAME New commit pushed here with changes for your comments: "invalid" -> "prohibited" Text is now: "Servers MUST NOT negotiate use of cipher suites unless the client supplies a supported . If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert." So, trying to find a viable cipher suite is preferred and the error is only required when there's nothing else to do. Edited to note: The latter doesn't contradict the mandatory error on negotiation without the needed extension, as the server simply has the (unlikely) chance of negotiating something completely different instead. The MAY error is still included later in the changeset, as discussed, so clients are still expected to always do this correctly or risk the server throwing an error.
NAME Ok, repushed with one-word change to clarify to "at least one group for each ephemeral key exchange algorithm". This excludes PSK, but is still fine for (EC)DHE when used with it. Seems like the simplest fix.