Draft: draft-ietf-tls-tls13

Commentary: As all error alerts are now considered fatal ( PR ) , we no longer need " This alert is always fatal " explicitly stated everywhere in that section .
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.
Paragraph (version A):
An inappropriate message was received.  This alert is always fatal
and should never be observed in communication between proper
implementations.
Paragraph (version A):
This alert is returned if a record is received which cannot be
deprotected.  Because AEAD algorithms combine decryption and
verification, this alert is used for all deprotection failures.
This alert is always fatal and should never be observed in
communication between proper implementations (except when messages
were corrupted in the network).
Paragraph (version A):
A TLSCiphertext record was received that had a length more than
2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record
with more than 2^14 bytes.  This alert is always fatal and should
never be observed in communication between proper implementations
(except when messages were corrupted in the network).
Paragraph (version A):
Reception of a "handshake_failure" alert message indicates that
the sender was unable to negotiate an acceptable set of security
parameters given the options available.  This alert is always
fatal.
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.  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 B):
An inappropriate message was received.  This alert should never be
observed in communication between proper implementations.
Paragraph (version B):
This alert is returned if a record is received which cannot be
deprotected.  Because AEAD algorithms combine decryption and
verification, this alert is used for all deprotection failures.
This alert should never be observed in communication between
proper implementations, except when messages were corrupted in the
network.
Paragraph (version B):
A TLSCiphertext record was received that had a length more than
2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record
with more than 2^14 bytes.  This alert should never be observed in
communication between proper implementations, except when messages
were corrupted in the network.
Paragraph (version B):
Reception of a "handshake_failure" alert message indicates that
the sender was unable to negotiate an acceptable set of security
parameters given the options available.
Paragraph (version A):
A field in the handshake was out of range or inconsistent with
other fields.  This alert is always fatal.
Paragraph (version A):
A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not
be located or couldn't be matched with a known, trusted CA.  This
alert is always fatal.
Paragraph (version A):
A valid certificate or PSK was received, but when access control
was applied, the sender decided not to proceed with negotiation.
This alert is always fatal.
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 is always fatal and should never be observed in
communication between proper implementations (except when messages
were corrupted in the network).
Paragraph (version A):
A handshake cryptographic operation failed, including being unable
to correctly verify a signature or validate a Finished message.
This alert is always fatal.
Paragraph (version A):
The protocol version the peer has attempted to negotiate is
recognized but not supported.  (For example, old protocol versions
might be avoided for security reasons.)  This alert is always
fatal.
Paragraph (version A):
Returned instead of "handshake_failure" when a negotiation has
failed specifically because the server requires ciphers more
secure than those supported by the client.  This alert is always
fatal.
Paragraph (version A):
An internal error unrelated to the peer or the correctness of the
protocol (such as a memory allocation failure) makes it impossible
to continue.  This alert is always fatal.
Paragraph (version A):
Sent by a server in response to an invalid connection retry
attempt from a client. (see [RFC7507]) This alert is always fatal.
Paragraph (version A):
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 B):
A field in the handshake was out of range or inconsistent with
other fields.
Paragraph (version B):
A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not
be located or couldn't be matched with a known, trusted CA.
Paragraph (version B):
A valid certificate or PSK was received, but when access control
was applied, the sender decided not to proceed with negotiation.
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 should never be observed in communication between proper
implementations, except when messages were corrupted in the
network.
Paragraph (version B):
A handshake cryptographic operation failed, including being unable
to correctly verify a signature or validate a Finished message.
Paragraph (version B):
Returned instead of "handshake_failure" when a negotiation has
failed specifically because the server requires ciphers more
secure than those supported by the client.
Paragraph (version B):
An internal error unrelated to the peer or the correctness of the
protocol (such as a memory allocation failure) makes it impossible
to continue.
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.
Paragraph (version A):
Sent by servers when a retrieved object does not have the correct
hash provided by the client via the "client_certificate_url"
extension RFC6066.  This alert is always fatal.
Paragraph (version B):
Sent by servers when a retrieved object does not have the correct
hash provided by the client via the "client_certificate_url"
extension RFC6066.