Draft: draft-ietf-tls-tls13

Commentary: 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 is n'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 some more , namely the fact that " clientkey_share " is clearly an error to be sent from a server . 
 & 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  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 . 
 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 does n'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 . 
 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 .
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
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.
Paragraph (version A):
Servers MUST NOT send this extension.  TLS servers MUST support
receiving this extension.
Paragraph (version B):
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.
Paragraph (version A):
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.
Paragraph (version B):
The "client_key_share" extension contains the client's cryptographic
parameters for zero or more non-PSK key establishment methods
(currently DHE or ECDHE).
Paragraph (version B):
Clients may offer an arbitrary number of ClientKeyShareOffer values,
each representing a single set of key agreement parameters; for
instance a client might offer shares for several elliptic curves or
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
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.
Paragraph (version A):
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.
Paragraph (version A):
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
MUST generate a fatal "handshake_failure" alert.
Paragraph (version B):
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.
Paragraph (version B):
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
MUST generate a fatal "unknown_psk_identity" alert and close the
connection.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.