Change:
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.

Discussion:
This message is always fatal.  [[TODO: IANA Considerations.]] <del> Sent by clients that receive an extended ServerHello containing an extension that they did not put in the corresponding ClientHello. This alert is always fatal. </del> <ins> Sent by endpoints receiving any hello message containing an extension known to be prohibited for inclusion in the given hello message, including any extensions in a ServerHello not first offered in the corresponding ClientHello.  This alert is always fatal. </ins> Sent by servers when unable to obtain a certificate from a URL

the server which signature/hash algorithm pairs may be used in digital signatures. <ins> All clients MUST send a valid "signature_algorithms" extension containing at least one supported SignatureAndHashAlgorithm when offering any certificate authenticated cipher suites.  Servers MUST NOT negotiate use of a certificate authenticated cipher suite unless the client supplies a supported SignatureAndHashAlgorithm.  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. </ins> The "extension_data" field of this extension contains a "supported_signature_algorithms" value:

algorithms.  server-certificate and server-key-share describe the appropriate rules. <del> All clients MUST send a valid "signature_algorithms" extension in their ClientHello when offering certificate authenticated cipher suites.  Servers receiving a TLS 1.3 ClientHello offering certificate authenticated cipher suites without this extension MUST send a "missing_extension" alert message and close the connection. Servers MUST NOT send this extension.  TLS servers MUST support receiving this extension. </del> Note: TLS 1.3 servers MAY receive TLS 1.2 ClientHellos which do not contain this extension.  If those servers are willing to negotiate TLS 1.2, they MUST behave in accordance with the requirements of

"elliptic_curves" and only contained elliptic curve groups.  See RFC4492 and I-D.ietf-tls-negotiated-ff-dhe. <ins> All clients MUST send a valid "supported_groups" extension containing at least one group for each ephemeral key exchange algorithm (currently DHE and ECDHE) for which it offers a cipher suite. Servers MUST NOT negotiate use of a DHE or ECDHE cipher suites unless the client supplies a supported NamedGroup.  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) If the extension is provided, but no compatible group is offered, the server MUST NOT negotiate a cipher suite of the relevant type.  For instance, if a client supplies only ECDHE groups, the server MUST NOT negotiate finite field Diffie-Hellman.  If no acceptable group can be selected across all cipher suites, then the server MUST generate a fatal "handshake_failure" alert. 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. </ins> The "extension_data" field of this extension contains a "NamedGroupList" value:

of the following octets.  Note that the first two octets indicate the extension type (Supported Group Extension): <del> The client MUST supply a "supported_groups" extension containing at least one group for each key exchange algorithm (currently DHE and ECDHE) for which it offers a cipher suite.  If the client does not supply a "supported_groups" extension with a compatible group, the server MUST NOT negotiate a cipher suite of the relevant type.  For instance, if a client supplies only ECDHE groups, the server MUST NOT negotiate finite field Diffie-Hellman.  If no acceptable group can be selected across all cipher suites, then the server MUST generate a fatal "handshake_failure" alert, or a "missing_extension" alert if no extension was provided. </del> NOTE: A server participating in an ECDHE-ECDSA key exchange may use different curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral ECDH key in the ServerKeyShare message.  The server

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

multiple integer DH groups.  The shares for each ClientKeyShareOffer MUST by generated independently.  Clients MUST NOT offer multiple ClientKeyShareOffers for the same parameters.  It is explicitly <del> permitted to send an empty client_key_share extension as this is used to elicit the server's parameters if the client has no useful information.  [TODO: Recommendation about what the client offers. Presumably which integer DH groups and which curves.] </del> <ins> permitted to send an empty "client_key_share" extension as this is used to elicit the server's parameters if the client has no useful information. [[TODO: Recommendation about what the client offers.  Presumably which integer DH groups and which curves.]] </ins> 6.3.2.3.1.

the pre-shared key to be used with a given handshake in association with a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background). <ins> All clients MUST send a valid "pre_shared_key" extension when offering any PSK cipher suites.  Servers MUST NOT negotiate use of a PSK cipher suite unless the client supplies a "pre_shared_key" 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) </ins> The "extension_data" field of this extension contains a "PreSharedKeyExtension" value:

An opaque label for the pre-shared key. <del> When the client offers a PSK cipher suite, it MUST also supply a PreSharedKeyExtension to indicate the PSK(s) to be used.  If no such extension is present, the server MUST NOT negotiate a PSK cipher suite.  If no suitable identity is present, the server MUST NOT negotiate a PSK cipher suite. </del> <ins> If no suitable identity is provided, the server MUST NOT negotiate a PSK cipher suite and MAY respond with an "unknown_psk_identity" alert message.  Sending this alert is OPTIONAL; servers MAY instead choose to send a "decrypt_error" alert to merely indicate an invalid PSK identity or instead negotiate use of a non-PSK cipher suite, if available. </ins> If the server selects a PSK cipher suite, it MUST send a PreSharedKeyExtension with the identity that it selected.  The client MUST verify that the server has selected one of the identities that the client supplied.  If any other identity is returned, the client <del> MUST generate a fatal "handshake_failure" alert. </del> <ins> MUST generate a fatal "unknown_psk_identity" alert and close the connection. </ins> 6.3.2.5.

Negotiated Groups ("supported_groups"; negotiated-groups) <del> All implementations MUST use the "signature_algorithms" extension when offering and negotiating certificate authenticated cipher suites.  All implementations MUST use the "supported_groups" extension when offering and negotiating DHE or ECDHE cipher suites. </del> <ins> Client Key Share ("client_key_share"; client-key-share) Pre-Shared Key Extension ("pre_shared_key"; pre-shared-key- extension) Server Name Indication ("server_name"; Section 3 of RFC6066) All implementations MUST send and use these extensions when offering applicable cipher suites: "signature_algorithms" is REQUIRED for certificate authenticated cipher suites "supported_groups" and "client_key_share" are REQUIRED for DHE or ECDHE cipher suites "pre_shared_key" is REQUIRED for PSK cipher suites When negotiating use of applicable cipher suites, endpoints MUST abort the connection with a "missing_extension" alert if the required extension was not provided.  Any endpoint that receives any invalid combination of cipher suites and extensions MAY abort the connection with a "missing_extension" alert, regardless of negotiated parameters. </ins> <del> [[TODO: also note client_key_share & pre_shared_key extensions]] [[OPEN ISSUE: MTI SNI under consideration]] </del> <ins> Additionally, all implementations MUST support use of the "server_name" extension with applications capable of using it. Servers MAY require clients to send a valid "server_name" extension. Servers requiring this extension SHOULD respond to a ClientHello lacking a "server_name" extension with a fatal "missing_extension" alert. </ins> 9.