Draft: draft-ietf-tls-rfc8446bis

Commentary: Based on the PSK authentication was not included in the past . I think specification has some places where " Client Authentication " refer to only certificate - based client authentication and not client authentication is general . Not a big thing , but I think it might confuse some readers , and would be good to clarify .
Paragraph (version A):
The client MUST send a Certificate message if and only if the server
has requested client authentication via a CertificateRequest message
(certificate-request).  If the server requests client authentication
but no suitable certificate is available, the client MUST send a
Certificate message containing no certificates (i.e., with the
"certificate_list" field having length 0).  A Finished message MUST
be sent regardless of whether the Certificate message is empty.
Paragraph (version B):
The client MUST send a Certificate message if and only if the server
has requested certificate-based client authentication via a
CertificateRequest message (certificate-request).  If the server
requests certificate-based client authentication but no suitable
certificate is available, the client MUST send a Certificate message
containing no certificates (i.e., with the "certificate_list" field
having length 0).  A Finished message MUST be sent regardless of
whether the Certificate message is empty.
Paragraph (version A):
Note: Although the resumption main secret depends on the client's
second flight, a server which does not request client authentication
MAY compute the remainder of the transcript independently and then
send a NewSessionTicket immediately upon sending its Finished rather
than waiting for the client Finished.  This might be appropriate in
cases where the client is expected to open multiple TLS connections
in parallel and would benefit from the reduced overhead of a
resumption handshake, for example.
Paragraph (version B):
Note: Although the resumption main secret depends on the client's
second flight, a server which does not request certificate-based
client authentication MAY compute the remainder of the transcript
independently and then send a NewSessionTicket immediately upon
sending its Finished rather than waiting for the client Finished.
This might be appropriate in cases where the client is expected to
open multiple TLS connections in parallel and would benefit from the
reduced overhead of a resumption handshake, for example.
Paragraph (version A):
When the client has sent the "post_handshake_auth" extension (see
post_handshake_auth), a server MAY request client authentication at
any time after the handshake has completed by sending a
CertificateRequest message.  The client MUST respond with the
appropriate Authentication messages (see authentication-messages).
If the client chooses to authenticate, it MUST send Certificate,
CertificateVerify, and Finished.  If it declines, it MUST send a
Certificate message containing no certificates followed by Finished.
All of the client's messages for a given response MUST appear
consecutively on the wire with no intervening messages of other
types.
Paragraph (version A):
Note: Because client authentication could involve prompting the user,
servers MUST be prepared for some delay, including receiving an
arbitrary number of other messages between sending the
CertificateRequest and receiving a response.  In addition, clients
which receive multiple CertificateRequests in close succession MAY
respond to them in a different order than they were received (the
certificate_request_context value allows the server to disambiguate
the responses).
Paragraph (version B):
When the client has sent the "post_handshake_auth" extension (see
post_handshake_auth), a server MAY request certificate-based client
authentication at any time after the handshake has completed by
sending a CertificateRequest message.  The client MUST respond with
the appropriate Authentication messages (see authentication-
messages).  If the client chooses to authenticate, it MUST send
Certificate, CertificateVerify, and Finished.  If it declines, it
MUST send a Certificate message containing no certificates followed
by Finished.  All of the client's messages for a given response MUST
appear consecutively on the wire with no intervening messages of
other types.
Paragraph (version B):
Note: Because certificate-based client authentication could involve
prompting the user, servers MUST be prepared for some delay,
including receiving an arbitrary number of other messages between
sending the CertificateRequest and receiving a response.  In
addition, clients which receive multiple CertificateRequests in close
succession MAY respond to them in a different order than they were
received (the certificate_request_context value allows the server to
disambiguate the responses).