Draft: draft-ietf-tls-tls13

Commentary: … e from the 9/2015 interim . Specifically : Use common language for failures Do n't require implementations to send alerts , but do require them to send specific alerts if they send them . 
 Should we have a blurb somewhere stating a recommendation for what sort of use cases we would expect a silent fail ? The main one that comes to mind is a server expecting PSK for client auth which could just reject invalid connections with no further response . ( side - note : I wish GitHub had a " submit all comments " button to allow reviewing and sending all at once in with a single notification . Instead , I just comment as I go , but that can get spammy quickly . :/ ) 
 My sense is that it 's not any particular use case that has a silent fail but rather implementations that do . 
 The first time alerts come up in the current document is in the " Incorrect DHE Share " section . I would consider adding a note at the end of the first paragraph in section 2 like " A failure of the handshake or other protocol error triggers the termination of the connection , optionally preceded by an alert message that may or may not be authenticated depending on how far the handshake progressed . " 
  at the interim was : All alerts shall be SHOULD to send ( or may in some cases ) In cases where alerts SHOULD be sent , there will be MUSTs for which one .
Paragraph (version B):
A failure of the handshake or other protocol error triggers the
termination of the connection, optionally preceded by an alert
message (alert-protocol).
Paragraph (version A):
If the client has not provided a sufficient "key_share" extension
(e.g., it includes only DHE or ECDHE groups unacceptable or
unsupported by the server), the server corrects the mismatch with a
HelloRetryRequest and the client needs to restart the handshake with
an appropriate "key_share" extension, as shown in Figure 2.  If no
common cryptographic parameters can be negotiated, the server sends a
"handshake_failure" or "insufficient_security" fatal alert (see
alert-protocol).
Paragraph (version B):
If the client has not provided a sufficient "key_share" extension
(e.g., it includes only DHE or ECDHE groups unacceptable or
unsupported by the server), the server corrects the mismatch with a
HelloRetryRequest and the client needs to restart the handshake with
an appropriate "key_share" extension, as shown in Figure 2.  If no
common cryptographic parameters can be negotiated, the server MUST
abort the handshake with an appropriate alert.
Paragraph (version B):
TLS defines two generic alerts (see alert-protocol) to use upon
failure to parse a message.  Peers which receive a message which
cannot be parsed according to the syntax (e.g., have a length
extending beyond the message boundary or contain an out-of-range
length) MUST terminate the connection with a "decoding_error" alert.
Peers which receive a message which is syntactically correct but
semantically invalid (e.g., a DHE share of p - 1) MUST terminate the
connection with an "illegal_parameter" alert.
Paragraph (version A):
Protocol messages MUST be sent in the order defined below (and shown
in the diagrams in protocol-overview).  Sending handshake messages in
an unexpected order results in an "unexpected_message" fatal error.
Unneeded handshake messages are omitted, however.
Paragraph (version B):
Protocol messages MUST be sent in the order defined below (and shown
in the diagrams in protocol-overview).  A peer which receives a
handshake message in an unexpected order MUST abort the handshake
with an "unexpected_message" alert.  results in an
"unexpected_message" fatal error.  Unneeded handshake messages are
omitted, however.
Paragraph (version A):
If the server is unable to negotiate a supported set of parameters
(i.e., there is no overlap between the client and server parameters),
it MUST return a "handshake_failure" alert and close the connection.
Paragraph (version B):
If the server is unable to negotiate a supported set of parameters
(i.e., there is no overlap between the client and server parameters),
it MUST abort the handshake and and SHOULD send either a
"handshake_failure" or "insufficient_security" fatal alert (see
alert-protocol).
Paragraph (version A):
If a server receives a ClientHello at any other time, it MUST send a
fatal "unexpected_message" alert and close the connection.
Paragraph (version A):
If a server established a TLS connection with a previous version of
TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST
retain the previous protocol version.  In particular, it MUST NOT
negotiate TLS 1.3.  A client that receives a TLS 1.3 ServerHello
during renegotiation MUST send a fatal "protocol_version" alert and
close the connection.
Paragraph (version B):
Because TLS 1.3 forbids renegotiation, if a server receives a
ClientHello at any other time, it MUST terminate the connection.
Paragraph (version B):
If a server established a TLS connection with a previous version of
TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST
retain the previous protocol version.  In particular, it MUST NOT
negotiate TLS 1.3.  A client that receives a TLS 1.3 ServerHello
during renegotiation MUST abort the handshake with a
"protocol_version" alert.
Paragraph (version A):
Versions of TLS before 1.3 supported compression with the list of
supported compression methods being sent in this field.  For every
TLS 1.3 ClientHello, this vector MUST contain exactly one byte set
to zero, which corresponds to the "null" compression method in
prior versions of TLS.  If a TLS 1.3 ClientHello is received with
any other value in this field, the server MUST generate a fatal
"illegal_parameter" alert.  Note that TLS 1.3 servers might
receive TLS 1.2 or prior ClientHellos which contain other
compression methods and MUST follow the procedures for the
appropriate prior version of TLS.
Paragraph (version B):
Versions of TLS before 1.3 supported compression with the list of
supported compression methods being sent in this field.  For every
TLS 1.3 ClientHello, this vector MUST contain exactly one byte set
to zero, which corresponds to the "null" compression method in
prior versions of TLS.  If a TLS 1.3 ClientHello is received with
any other value in this field, the server MUST abort the handshake
with an "illegal_parameter" alert.  Note that TLS 1.3 servers
might receive TLS 1.2 or prior ClientHellos which contain other
compression methods and MUST follow the procedures for the
appropriate prior version of TLS.
Paragraph (version A):
In the event that a client requests additional functionality using
extensions, and this functionality is not supplied by the server, the
client MAY abort the handshake.  Note that TLS 1.3 ClientHello
messages MUST always contain extensions, and a TLS 1.3 server MUST
respond to any TLS 1.3 ClientHello without extensions with a fatal
"decode_error" alert.  TLS 1.3 servers may receive TLS 1.2
ClientHello messages without extensions.  If negotiating TLS 1.2, a
server MUST check that the amount of data in the message precisely
matches one of these formats; if not, then it MUST send a fatal
"decode_error" alert.
Paragraph (version B):
In the event that a client requests additional functionality using
extensions, and this functionality is not supplied by the server, the
client MAY abort the handshake.  Note that TLS 1.3 ClientHello
messages MUST always contain extensions, and a TLS 1.3 server MUST
respond to any TLS 1.3 ClientHello without extensions or with data
following the extensions block with a "decode_error" alert.  TLS 1.3
servers may receive TLS 1.2 ClientHello messages without extensions.
If negotiating TLS 1.2, a server MUST check that the message either
contains no data after legacy_compression_methods or that it contains
a valid extensions block with no data following.  If not, then it
MUST abort the handshake with a "decode_error" alert.
Paragraph (version A):
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites.
Paragraph (version B):
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites.  A client which receives a cipher suite
that was not offered MUST abort the handshake.
Paragraph (version A):
A list of extensions.  Note that only extensions offered by the
client can appear in the server's list.  In TLS 1.3, as opposed to
previous versions of TLS, the server's extensions are split
between the ServerHello and the EncryptedExtensions encrypted-
extensions message.  The ServerHello MUST only include extensions
which are required to establish the cryptographic context.
Currently the only such extensions are "key_share",
"pre_shared_key", and "signature_algorithms".  Clients MUST check
the ServerHello for the presence of any forbidden extensions and
if any are found MUST terminate the handshake with a
"illegal_parameter" alert.  In prior versions of TLS, the
extensions field could be omitted entirely if not needed, similar
to ClientHello.  As of TLS 1.3, all clients and servers will send
at least one extension (at least "key_share" or "pre_shared_key").
Paragraph (version B):
A list of extensions.  Note that only extensions offered by the
client can appear in the server's list.  In TLS 1.3, as opposed to
previous versions of TLS, the server's extensions are split
between the ServerHello and the EncryptedExtensions encrypted-
extensions message.  The ServerHello MUST only include extensions
which are required to establish the cryptographic context.
Currently the only such extensions are "key_share",
"pre_shared_key", and "signature_algorithms".  Clients MUST check
the ServerHello for the presence of any forbidden extensions and
if any are found MUST abort the handshake with a
"illegal_parameter" alert.  In prior versions of TLS, the
extensions field could be omitted entirely if not needed, similar
to ClientHello.  As of TLS 1.3, all clients and servers will send
at least one extension (at least "key_share" or "pre_shared_key").
Paragraph (version A):
TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check
that the last eight octets are not equal to either of these values.
TLS 1.2 clients SHOULD also perform this check if the ServerHello
indicates TLS 1.1 or below.  If a match is found, the client MUST
abort the handshake with a fatal "illegal_parameter" alert.  This
mechanism provides limited protection against downgrade attacks over
and above that provided by the Finished exchange: because the
ServerKeyExchange includes a signature over both random values, it is
not possible for an active attacker to modify the randoms without
detection as long as ephemeral ciphers are used.  It does not provide
downgrade protection when static RSA is used.
Paragraph (version B):
TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check
that the last eight octets are not equal to either of these values.
TLS 1.2 clients SHOULD also perform this check if the ServerHello
indicates TLS 1.1 or below.  If a match is found, the client MUST
abort the handshake with an "illegal_parameter" alert.  This
mechanism provides limited protection against downgrade attacks over
and above that provided by the Finished exchange: because the
ServerKeyExchange includes a signature over both random values, it is
not possible for an active attacker to modify the randoms without
detection as long as ephemeral ciphers are used.  It does not provide
downgrade protection when static RSA is used.
Paragraph (version A):
Servers send this message in response to a ClientHello message if
they were able to find an acceptable set of algorithms and groups
that are mutually supported, but the client's ClientHello did not
contain sufficient information to proceed with the handshake.  If
a server cannot successfully select algorithms, it will respond
with a fatal "handshake_failure" alert instead.
Paragraph (version B):
Servers send this message in response to a ClientHello message if
they were able to find an acceptable set of algorithms and groups
that are mutually supported, but the client's ClientHello did not
contain sufficient information to proceed with the handshake.  If
a server cannot successfully select algorithms, it MUST abort the
handshake with a "handshake_failure" alert.
Paragraph (version A):
Upon receipt of a HelloRetryRequest, the client MUST verify that the
extensions block is not empty and otherwise abort the handshake with
a fatal "decode_error" alert.  Clients SHOULD also abort with
"unexpected_message" in response to any second HelloRetryRequest
which was sent in the same connection (i.e., where the ClientHello
was itself in response to a HelloRetryRequest).
Paragraph (version B):
Upon receipt of a HelloRetryRequest, the client MUST verify that the
extensions block is not empty and otherwise MUST abort the handshake
with a "decode_error" alert.  Clients SHOULD also abort the handshake
with an "unexpected_message" alert in response to any second
HelloRetryRequest which was sent in the same connection (i.e., where
the ClientHello was itself in response to a HelloRetryRequest).
Paragraph (version A):
The client uses the "signature_algorithms" extension to indicate to
the server which signature algorithms may be used in digital
signatures.  Clients which desire the server to authenticate via a
certificate MUST send this extension.  If a server is authenticating
via a certificate and the client has not sent a
"signature_algorithms" extension then the server MUST close the
connection with a fatal "missing_extension" alert (see mti-
extensions).
Paragraph (version B):
The client uses the "signature_algorithms" extension to indicate to
the server which signature algorithms may be used in digital
signatures.  Clients which desire the server to authenticate via a
certificate MUST send this extension.  If a server is authenticating
via a certificate and the client has not sent a
"signature_algorithms" extension then the server MUST abort the
handshake with a "missing_extension" alert (see mti-extensions).
Paragraph (version A):
Clients offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters.  For instance,
a client might offer shares for several elliptic curves or multiple
FFDHE groups.  The key_exchange values for each KeyShareEntry MUST by
generated independently.  Clients MUST NOT offer multiple
KeyShareEntry values for the same group.  Clients MUST NOT offer any
KeyShareEntry values for groups not listed in the client's
"supported_groups" extension.  Servers MAY check for violations of
these rules and and MAY abort the connection with a fatal
"illegal_parameter" alert if one is violated.
Paragraph (version B):
Clients offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters.  For instance,
a client might offer shares for several elliptic curves or multiple
FFDHE groups.  The key_exchange values for each KeyShareEntry MUST by
generated independently.  Clients MUST NOT offer multiple
KeyShareEntry values for the same group.  Clients MUST NOT offer any
KeyShareEntry values for groups not listed in the client's
"supported_groups" extension.  Servers MAY check for violations of
these rules and and MAY abort the handshake with an
"illegal_parameter" alert if one is violated.
Paragraph (version A):
Upon receipt of this extension in a HelloRetryRequest, the client
MUST first verify that the selected_group field corresponds to a
group which was provided in the "supported_groups" extension in the
original ClientHello.  It MUST then verify that the selected_group
field does not correspond to a group which was provided in the
"key_share" extension in the original ClientHello.  If either of
these checks fails, then the client MUST abort the handshake with a
fatal "illegal_parameter" alert.  Otherwise, when sending the new
ClientHello, the client MUST append a new KeyShareEntry for the group
indicated in the selected_group field to the groups in its original
KeyShare.  The remaining KeyShareEntry values MUST be preserved.
Paragraph (version B):
Upon receipt of this extension in a HelloRetryRequest, the client
MUST first verify that the selected_group field corresponds to a
group which was provided in the "supported_groups" extension in the
original ClientHello.  It MUST then verify that the selected_group
field does not correspond to a group which was provided in the
"key_share" extension in the original ClientHello.  If either of
these checks fails, then the client MUST abort the handshake with an
"illegal_parameter" alert.  Otherwise, when sending the new
ClientHello, the client MUST append a new KeyShareEntry for the group
indicated in the selected_group field to the groups in its original
KeyShare.  The remaining KeyShareEntry values MUST be preserved.
Paragraph (version A):
If using (EC)DHE key establishment, servers offer exactly one
KeyShareEntry in the ServerHello.  This value MUST correspond to the
KeyShareEntry value offered by the client that the server has
selected for the negotiated key exchange.  Servers MUST NOT send a
KeyShareEntry for any group not indicated in the "supported_groups"
extension.  If a HelloRetryRequest was received, the client MUST
verify that the selected NamedGroup matches that supplied in the
selected_group field and MUST abort the connection with a fatal
"illegal_parameter" alert if it does not.
Paragraph (version B):
If using (EC)DHE key establishment, servers offer exactly one
KeyShareEntry in the ServerHello.  This value MUST correspond to the
KeyShareEntry value offered by the client that the server has
selected for the negotiated key exchange.  Servers MUST NOT send a
KeyShareEntry for any group not indicated in the "supported_groups"
extension.  If a HelloRetryRequest was received, the client MUST
verify that the selected NamedGroup matches that supplied in the
selected_group field and MUST abort the connection with an
"illegal_parameter" alert if it does not.
Paragraph (version A):
In order to accept PSK key establishment, the server sends a
"pre_shared_key" extension with the selected identity.  Clients MUST
verify that the server's selected_identity is within the range
supplied by the client and that the "key_share" and
"signature_algorithms" extensions are consistent with the indicated
ke_modes and auth_modes values.  If these values are not consistent,
the client MUST generate an "illegal_parameter" alert and close the
connection.
Paragraph (version A):
If the server supplies an "early_data" extension, the client MUST
verify that the server selected the first offered identity.  If any
other value is returned, the client MUST generate a fatal
"unknown_psk_identity" alert and close the connection.
Paragraph (version B):
In order to accept PSK key establishment, the server sends a
"pre_shared_key" extension with the selected identity.  Clients MUST
verify that the server's selected_identity is within the range
supplied by the client and that the "key_share" and
"signature_algorithms" extensions are consistent with the indicated
ke_modes and auth_modes values.  If these values are not consistent,
the client MUST abort the handshake with an "illegal_parameter"
alert.
Paragraph (version B):
If the server supplies an "early_data" extension, the client MUST
verify that the server selected the first offered identity.  If any
other value is returned, the client MUST abort the handshake with an
"unknown_psk_identity" alert.
Paragraph (version B):
If the server chooses to accept the "early_data" extension, then it
MUST comply with the same error handling requirements specified for
all records when processing early data records.  Specifically, if the
server fails to decrypt any 0-RTT record following an accepted
"early_data" extension it MUST terminate the connection with a
"bad_record_mac" alert as per record-payload-protection.
Paragraph (version A):
The same extension types MUST NOT appear in both the ServerHello and
EncryptedExtensions.  All server-sent extensions other than those
explicitly listed in server-hello or designated in the IANA registry
MUST only appear in EncryptedExtensions.  Extensions which are
designated to appear in ServerHello MUST NOT appear in
EncryptedExtensions.  Clients MUST check EncryptedExtensions for the
presence of any forbidden extensions and if any are found MUST
terminate the handshake with an "illegal_parameter" alert.
Paragraph (version B):
The same extension types MUST NOT appear in both the ServerHello and
EncryptedExtensions.  All server-sent extensions other than those
explicitly listed in server-hello or designated in the IANA registry
MUST only appear in EncryptedExtensions.  Extensions which are
designated to appear in ServerHello MUST NOT appear in
EncryptedExtensions.  Clients MUST check EncryptedExtensions for the
presence of any forbidden extensions and if any are found MUST abort
the handshake with an "illegal_parameter" alert.
Paragraph (version A):
If the server cannot produce a certificate chain that is signed only
via the indicated supported algorithms, then it SHOULD continue the
handshake by sending the client a certificate chain of its choice
that may include algorithms that are not known to be supported by the
client.  This fallback chain MAY use the deprecated SHA-1 hash
algorithm only if the "signature_algorithms" extension provided by
the client permits it.  If the client cannot construct an acceptable
chain using the provided certificates and decides to abort the
handshake, then it MUST send an "unsupported_certificate" alert
message and close the connection.
Paragraph (version B):
If the server cannot produce a certificate chain that is signed only
via the indicated supported algorithms, then it SHOULD continue the
handshake by sending the client a certificate chain of its choice
that may include algorithms that are not known to be supported by the
client.  This fallback chain MAY use the deprecated SHA-1 hash
algorithm only if the "signature_algorithms" extension provided by
the client permits it.  If the client cannot construct an acceptable
chain using the provided certificates and decides to abort the
handshake, then it MUST abort the handshake with an
"unsupported_certificate" alert.
Paragraph (version A):
If the server supplies an empty Certificate message, the client MUST
terminate the handshake with a fatal "decode_error" alert.
Paragraph (version A):
If the client does not send any certificates, the server MAY at its
discretion either continue the handshake without client
authentication, or respond with a fatal "handshake_failure" alert.
Also, if some aspect of the certificate chain was unacceptable (e.g.,
it was not signed by a known, trusted CA), the server MAY at its
discretion either continue the handshake (considering the client
unauthenticated) or send a fatal alert.
Paragraph (version A):
Any endpoint receiving any certificate signed using any signature
algorithm using an MD5 hash MUST send a "bad_certificate" alert
message and close the connection.  SHA-1 is deprecated and therefore
NOT RECOMMENDED.  All endpoints are RECOMMENDED to transition to
SHA-256 or better as soon as possible to maintain interoperability
with implementations currently in the process of phasing out SHA-1
support.
Paragraph (version B):
If the server supplies an empty Certificate message, the client MUST
abort the handshake with a "decode_error" alert.
Paragraph (version B):
If the client does not send any certificates, the server MAY at its
discretion either continue the handshake without client
authentication, or abort the handshake with a "handshake_failure"
alert.  Also, if some aspect of the certificate chain was
unacceptable (e.g., it was not signed by a known, trusted CA), the
server MAY at its discretion either continue the handshake
(considering the client unauthenticated) or abort the handshake.
Paragraph (version B):
Any endpoint receiving any certificate signed using any signature
algorithm using an MD5 hash MUST abort the handshake with a
"bad_certificate" alert.  SHA-1 is deprecated and it is RECOMMENDED
that any endpoint receiving any certificate signed using any
signature algorithm using a SHA-1 hash abort the handshake with a
"bad_certificate" alert.  All endpoints are RECOMMENDED to transition
to SHA-256 or better as soon as possible to maintain interoperability
with implementations currently in the process of phasing out SHA-1
support.
Paragraph (version A):
Endpoints that reject certification paths due to use of a deprecated
hash MUST send a fatal "bad_certificate" alert message before closing
the connection.
Paragraph (version A):
The KeyUpdate handshake message is used to indicate that the sender
is updating its sending cryptographic keys.  This message can be sent
by the server after sending its first flight and the client after
sending its second flight.  Implementations that receive a KeyUpdate
message prior to receiving a Finished message as part of the 1-RTT
handshake MUST generate a fatal "unexpected_message" alert.  After
sending a KeyUpdate message, the sender SHALL send all its traffic
using the next generation of keys, computed as described in updating-
traffic-keys.  Upon receiving a KeyUpdate, the receiver MUST update
their receiving keys and if they have not already updated their
sending state up to or past the then current receiving generation
MUST send their own KeyUpdate prior to sending any other messages.
This mechanism allows either side to force an update to the entire
connection.  Note that implementations may receive an arbitrary
number of messages between sending a KeyUpdate and receiving the
peer's KeyUpdate because those messages may already be in flight.
Paragraph (version B):
The KeyUpdate handshake message is used to indicate that the sender
is updating its sending cryptographic keys.  This message can be sent
by the server after sending its first flight and the client after
sending its second flight.  Implementations that receive a KeyUpdate
message prior to receiving a Finished message as part of the 1-RTT
handshake MUST terminate the connection with an "unexpected_message"
alert.  After sending a KeyUpdate message, the sender SHALL send all
its traffic using the next generation of keys, computed as described
in updating-traffic-keys.  Upon receiving a KeyUpdate, the receiver
MUST update their receiving keys and if they have not already updated
their sending state up to or past the then current receiving
generation MUST send their own KeyUpdate prior to sending any other
messages.  This mechanism allows either side to force an update to
the entire connection.  Note that implementations may receive an
arbitrary number of messages between sending a KeyUpdate and
receiving the peer's KeyUpdate because those messages may already be
in flight.
Paragraph (version A):
Handshake messages MUST NOT span key changes.  Because the
ServerHello, Finished, and KeyUpdate messages signal a key change,
upon receiving these messages a receiver MUST verify that the end of
these messages aligns with a record boundary; if not, then it MUST
send a fatal "unexpected_message" alert.
Paragraph (version B):
Handshake messages MUST NOT span key changes.  Because the
ServerHello, Finished, and KeyUpdate messages signal a key change,
upon receiving these messages a receiver MUST verify that the end of
these messages aligns with a record boundary; if not, then it MUST
terminate the connection with an "unexpected_message" alert.
Paragraph (version A):
TLS records are typed, which allows multiple higher level protocols
to be multiplexed over the same record layer.  This document
specifies three content types: handshake, application data, and
alert.  Implementations MUST NOT send record types not defined in
this document unless negotiated by some extension.  If a TLS
implementation receives an unexpected record type, it MUST send an
"unexpected_message" alert.  New record content type values are
assigned by IANA in the TLS Content Type Registry as described in
iana-considerations.
Paragraph (version B):
TLS records are typed, which allows multiple higher level protocols
to be multiplexed over the same record layer.  This document
specifies three content types: handshake, application data, and
alert.  Implementations MUST NOT send record types not defined in
this document unless negotiated by some extension.  If a TLS
implementation receives an unexpected record type, it MUST terminate
the connection with an "unexpected_message" alert.  New record
content type values are assigned by IANA in the TLS Content Type
Registry as described in iana-considerations.
Paragraph (version A):
The length (in bytes) of the following TLSCiphertext.fragment,
which is the sum of the lengths of the content and the padding,
plus one for the inner content type.  The length MUST NOT exceed
2^14 + 256.  An endpoint that receives a record that exceeds this
length MUST generate a fatal "record_overflow" alert.
Paragraph (version B):
The length (in bytes) of the following TLSCiphertext.fragment,
which is the sum of the lengths of the content and the padding,
plus one for the inner content type.  The length MUST NOT exceed
2^14 + 256.  An endpoint that receives a record that exceeds this
length MUST terminate the connection with a "record_overflow"
alert.
Paragraph (version A):
If the decryption fails, a fatal "bad_record_mac" alert MUST be
generated.
Paragraph (version A):
An AEAD cipher MUST NOT produce an expansion of greater than 255
bytes.  An endpoint that receives a record from its peer with
TLSCipherText.length larger than 2^14 + 256 octets MUST generate a
fatal "record_overflow" alert.  This limit is derived from the
maximum TLSPlaintext length of 2^14 octets + 1 octet for ContentType
+ the maximum AEAD expansion of 255 octets.
Paragraph (version B):
If the decryption fails, the receiver MUST terminate the connection
with a "bad_record_mac" alert.
Paragraph (version B):
An AEAD cipher MUST NOT produce an expansion of greater than 255
bytes.  An endpoint that receives a record from its peer with
TLSCipherText.length larger than 2^14 + 256 octets MUST terminate the
connection with a "record_overflow" alert.  This limit is derived
from the maximum TLSPlaintext length of 2^14 octets + 1 octet for
ContentType + the maximum AEAD expansion of 255 octets.
Paragraph (version A):
Implementations MUST limit their scanning to the cleartext returned
from the AEAD decryption.  If a receiving implementation does not
find a non-zero octet in the cleartext, it should treat the record as
having an unexpected ContentType, sending an "unexpected_message"
alert.
Paragraph (version B):
Implementations MUST limit their scanning to the cleartext returned
from the AEAD decryption.  If a receiving implementation does not
find a non-zero octet in the cleartext, it MUST terminate the
connection with an "unexpected_message" alert.
Paragraph (version A):
Error handling in the TLS Handshake Protocol is very simple.  When an
error is detected, the detecting party sends a message to its peer.
Upon transmission or receipt of a fatal alert message, both parties
immediately close the connection.  Whenever an implementation
encounters a condition which is defined as a fatal alert, it MUST
send the appropriate alert prior to closing the connection.  All
alerts defined in this section below, as well as all unknown alerts
are universally considered fatal as of TLS 1.3 (see alert-protocol).
Paragraph (version A):
An inappropriate message was received.  This alert should never be
observed in communication between proper implementations.
Paragraph (version B):
Error handling in the TLS Handshake Protocol is very simple.  When an
error is detected, the detecting party sends a message to its peer.
Upon transmission or receipt of a fatal alert message, both parties
immediately close the connection.
Paragraph (version B):
Whenever an implementation encounters a fatal error condition, it
SHOULD send an appropriate fatal alert and MUST close the connection
without sending or receiving any additional data.  In the rest of
this specification, the phrase "{terminate the connection, abort the
handshake}" is used without a specific alert means that the
implementation SHOULD send the alert indicated by the descriptions
below.  The phrase "{terminate the connection, abort the handshake}
with a X alert" MUST send alert X if it sends any alert.  All alerts
defined in this section below, as well as all unknown alerts are
universally considered fatal as of TLS 1.3 (see alert-protocol).
Paragraph (version B):
An inappropriate message (e.g., the wrong handshake message,
premature application data, etc.) was received.  This alert should
never be observed in communication between proper implementations.
Paragraph (version A):
A field in the handshake was out of range or inconsistent with
other fields.
Paragraph (version B):
A field in the handshake was incorrect or inconsistent with other
fields.  This alert is used for errors which conform to the formal
protocol syntax but are otherwise incorrect.
Paragraph (version A):
A message could not be decoded because some field was out of the
specified range or the length of the message was incorrect.  This
alert should never be observed in communication between proper
implementations, except when messages were corrupted in the
network.
Paragraph (version B):
A message could not be decoded because some field was out of the
specified range or the length of the message was incorrect.  This
alert is used for errors where the message does not conform to the
formal protocol syntax.  This alert should never be observed in
communication between proper implementations, except when messages
were corrupted in the network.
Paragraph (version A):
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):
When negotiating use of applicable cipher suites, endpoints MUST
abort the handshake 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 A):
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.
Paragraph (version A):
Servers MUST NOT send the "signature_algorithms" extension; if a
client receives this extension it MUST respond with a fatal
"unsupported_extension" alert and close the connection.
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 by terminating the connection with
a "missing_extension" alert.