Draft: draft-ietf-tls-tls13

Commentary: Sometimes the alert name is in between quotes like : " protocolversion " alert .. and sometimes it is not ... like : closenotify alert 
 First commit : fix typos Other commits : I made all alert names citations consistent across the text by adding quotes when missing B. 
 BTW - I noted the same inconsistencies .
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
If the decryption fails, a fatal bad_record_mac alert MUST be
generated.
Paragraph (version B):
If the decryption fails, a fatal "bad_record_mac" alert MUST be
generated.
Paragraph (version A):
Either party MAY initiate a close by sending a close_notify alert.
Any data received after a closure alert is ignored.
Paragraph (version A):
Unless some other fatal alert has been transmitted, each party is
required to send a close_notify alert before closing the write side
of the connection.  The other party MUST respond with a close_notify
alert of its own and close down the connection immediately,
discarding any pending writes.  It is not required for the initiator
of the close to wait for the responding close_notify alert before
closing the read side of the connection.
Paragraph (version A):
If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is
closed, the TLS implementation must receive the responding
close_notify alert before indicating to the application layer that
the TLS connection has ended.  If the application protocol will not
transfer any additional data, but will only close the underlying
transport connection, then the implementation MAY choose to close the
transport without waiting for the responding close_notify.  No part
of this standard should be taken to dictate the manner in which a
usage profile for TLS manages its data transport, including when
connections are opened or closed.
Paragraph (version B):
Either party MAY initiate a close by sending a "close_notify" alert.
Any data received after a closure alert is ignored.
Paragraph (version B):
Unless some other fatal alert has been transmitted, each party is
required to send a "close_notify" alert before closing the write side
of the connection.  The other party MUST respond with a
"close_notify" alert of its own and close down the connection
immediately, discarding any pending writes.  It is not required for
the initiator of the close to wait for the responding "close_notify"
alert before closing the read side of the connection.
Paragraph (version B):
If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is
closed, the TLS implementation must receive the responding
"close_notify" alert before indicating to the application layer that
the TLS connection has ended.  If the application protocol will not
transfer any additional data, but will only close the underlying
transport connection, then the implementation MAY choose to close the
transport without waiting for the responding "close_notify".  No part
of this standard should be taken to dictate the manner in which a
usage profile for TLS manages its data transport, including when
connections are opened or closed.
Paragraph (version A):
If an alert with a level of warning is sent and received, generally
the connection can continue normally.  If the receiving party decides
not to proceed with the connection (e.g., after having received a
no_renegotiation alert that it is not willing to accept), it SHOULD
send a fatal alert to terminate the connection.  Given this, the
sending party cannot, in general, know how the receiving party will
behave.  Therefore, warning alerts are not very useful when the
sending party wants to continue the connection, and thus are
sometimes omitted.  For example, if a peer decides to accept an
expired certificate (perhaps after confirming this with the user) and
wants to continue the connection, it would not generally send a
certificate_expired alert.
Paragraph (version B):
If an alert with a level of warning is sent and received, generally
the connection can continue normally.  If the receiving party decides
not to proceed with the connection (e.g., after having received a
"no_renegotiation" alert that it is not willing to accept), it SHOULD
send a fatal alert to terminate the connection.  Given this, the
sending party cannot, in general, know how the receiving party will
behave.  Therefore, warning alerts are not very useful when the
sending party wants to continue the connection, and thus are
sometimes omitted.  For example, if a peer decides to accept an
expired certificate (perhaps after confirming this with the user) and
wants to continue the connection, it would not generally send a
"certificate_expired" alert.
Paragraph (version A):
certificate_expired alert.
Paragraph (version B):
"certificate_expired" alert.
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 message is always
fatal.
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.  This message 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 message is always
fatal.
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.  This message is always
fatal.
Paragraph (version A):
This handshake is being canceled for some reason unrelated to a
protocol failure.  If the user cancels an operation after the
handshake is complete, just closing the connection by sending a
close_notify is more appropriate.  This alert should be followed
by a close_notify.  This message is generally a warning.
Paragraph (version B):
This handshake is being canceled for some reason unrelated to a
protocol failure.  If the user cancels an operation after the
handshake is complete, just closing the connection by sending a
"close_notify" is more appropriate.  This alert should be followed
by a "close_notify".  This message is generally a warning.
Paragraph (version A):
When a client first connects to a server, it is required to send
the ClientHello as its first message.  The client will also send a
ClientHello when the server has responded to its ClientHello with
a ServerHello that selects cryptographic parameters that don't
match the client's ClientKeyShare.  In that case, the client MUST
send the same ClientHello (without modification) along with the
new ClientKeyShare.  If a server receives a ClientHello at any
other time, it MUST send a fatal no_renegotiation alert.
Paragraph (version B):
When a client first connects to a server, it is required to send
the ClientHello as its first message.  The client will also send a
ClientHello when the server has responded to its ClientHello with
a ServerHello that selects cryptographic parameters that don't
match the client's ClientKeyShare.  In that case, the client MUST
send the same ClientHello (without modification) along with the
new ClientKeyShare.  If a server receives a ClientHello at any
other time, it MUST send a fatal "no_renegotiation" alert.
Paragraph (version A):
The cipher suite list, passed from the client to the server in the
ClientHello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's
preference (favorite choice first).  Each cipher suite defines a key
exchange algorithm, a record protection algorithm (including secret
key length) and a PRF.  The server will select a cipher suite or, if
no acceptable choices are presented, return a handshake failure alert
and close the connection.  If the list contains cipher suites the
server does not recognize, support, or wish to use, the server MUST
ignore those cipher suites, and process the remaining ones as usual.
Paragraph (version B):
The cipher suite list, passed from the client to the server in the
ClientHello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's
preference (favorite choice first).  Each cipher suite defines a key
exchange algorithm, a record protection algorithm (including secret
key length) and a PRF.  The server will select a cipher suite or, if
no acceptable choices are presented, return a "handshake_failure"
alert and close the connection.  If the list contains cipher suites
the server does not recognize, support, or wish to use, the server
MUST ignore those cipher suites, and process the remaining ones as
usual.
Paragraph (version A):
The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms
and the client's ClientKeyShare message was acceptable.  If the
client proposed groups are not acceptable by the server, it will
respond with an insufficient_security fatal alert.
Paragraph (version B):
The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms
and the client's ClientKeyShare message was acceptable.  If the
client proposed groups are not acceptable by the server, it will
respond with an "insufficient_security" fatal alert.
Paragraph (version A):
The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms
but the client's ClientKeyShare message did not contain an
acceptable offer.  If it cannot find such a match, it will respond
with a handshake failure alert.
Paragraph (version B):
The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms
but the client's ClientKeyShare message did not contain an
acceptable offer.  If it cannot find such a match, it will respond
with a "handshake_failure" alert.
Paragraph (version A):
An extension type MUST NOT appear in the ServerHello unless the same
extension type appeared in the corresponding ClientHello.  If a
client receives an extension type in ServerHello that it did not
request in the associated ClientHello, it MUST abort the handshake
with an unsupported_extension fatal alert.
Paragraph (version B):
An extension type MUST NOT appear in the ServerHello unless the same
extension type appeared in the corresponding ClientHello.  If a
client receives an extension type in ServerHello that it did not
request in the associated ClientHello, it MUST abort the handshake
with an "unsupported_extension" fatal alert.
Paragraph (version A):
Note: It is a fatal handshake_failure alert for an anonymous server
to request client authentication.
Paragraph (version B):
Note: It is a fatal "handshake_failure" alert for an anonymous server
to request client authentication.
Paragraph (version A):
This message is the first handshake message the client can send
after receiving the server's Finished.  This message is only sent
if the server requests a certificate.  If no suitable certificate
is available, the client MUST send a certificate message
containing no certificates.  That is, the certificate_list
structure has a length of zero.  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 B):
This message is the first handshake message the client can send
after receiving the server's Finished.  This message is only sent
if the server requests a certificate.  If no suitable certificate
is available, the client MUST send a certificate message
containing no certificates.  That is, the certificate_list
structure has a length of zero.  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.