Draft: draft-ietf-tls-rfc8446bis

Commentary: Change " should " -"SHOULD " around user_canceled Replicate the 8773 language to another place where external PSKs is discussed . Remove an OPEN ISSUE marker
Paragraph (version A):
TLS is application protocol independent; higher-level protocols can
layer on top of TLS transparently.  The TLS standard, however, does
not specify how protocols add security with TLS; how to initiate TLS
handshaking and how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors
of protocols that run on top of TLS.  Application protocols using TLS
MUST specify how TLS works with their application protocol, including
how and when handshaking occurs, and how to do identity verification.
I-D.ietf-uta-rfc6125bis provides useful guidance on integrating TLS
with applicaiton protocols.
Paragraph (version B):
TLS is application protocol independent; higher-level protocols can
layer on top of TLS transparently.  The TLS standard, however, does
not specify how protocols add security with TLS; how to initiate TLS
handshaking and how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors
of protocols that run on top of TLS.  Application protocols using TLS
MUST specify how TLS works with their application protocol, including
how and when handshaking occurs, and how to do identity verification.
I-D.ietf-uta-rfc6125bis provides useful guidance on integrating TLS
with application protocols.
Paragraph (version A):
TLS 1.3 was originally specified in RFC8446.  This document is solely
an editorial update.  It contains updated text in areas which were
found to be unclear as well as other editorial improvements.  In
addition, it removes the use of the term "master" as applied to
secrets in favor of the term "main" or shorter names where no term
was neccessary.
Paragraph (version B):
Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by
RFC8996.
Paragraph (version B):
Removes ambiguity around which hash is used with PreSharedKeys and
HelloRetryRequest.
Paragraph (version B):
Require that clients ignore NewSessionTicket if they do not
support resumption.
Paragraph (version B):
Upgrade the requirement to initiate key update before exceeding
key usage limits to MUST.
Paragraph (version B):
Limit the number of permitted KeyUpdate messages.
Paragraph (version B):
Restore text defining the level of "close_notify" to "warning".
Clarify behavior around "user_canceled", requiring that
"close_notify" be sent and that "user_canceled" should be ignored.
Paragraph (version B):
Add a "general_error" generic alert.
Paragraph (version B):
In addition, there have been some improvements to the security
considerations, especially around privacy.
Paragraph (version A):
Servers which are authenticating with a resumption PSK MUST NOT send
the CertificateRequest message in the main handshake, though they MAY
send it in post-handshake authentication (see post-handshake-
authentication) provided that the client has sent the
"post_handshake_auth" extension (see post_handshake_auth).  Servers
which are authenticating with an external PSK MUST NOT send the
CertificateRequest message either in the main handshake or request
post-handshake authentication.  Future specifications MAY provide an
extension to permit this.
Paragraph (version B):
Servers which are authenticating with a resumption PSK MUST NOT send
the CertificateRequest message in the main handshake, though they MAY
send it in post-handshake authentication (see post-handshake-
authentication) provided that the client has sent the
"post_handshake_auth" extension (see post_handshake_auth).  In the
absence of some other specification to the contrary, servers which
are authenticating with an external PSK MUST NOT send the
CertificateRequest message either in the main handshake or request
post-handshake authentication.  RFC8773 provides an extension to
permit this, but has not received the level of analysis as this
specification.