Draft: draft-ietf-tls-tls13

Commentary: lgtm 
 LGTM
Paragraph (version B):
Add "post_handshake_auth" extension to negotiate post-handshake
authentication (*).
Paragraph (version B):
The "post_handshake_auth" extension is used to indicate that a client
is willing to perform post-handshake authentication post-handshake-
authentication.  Servers MUST not send a post-handshake
CertificateRequest to clients which do not offer this extension.
Paragraph (version B):
The "extension_data" field of the "post_handshake_auth" extension is
zero length.
Paragraph (version A):
If the certificate_authorities list in the CertificateRequest
message was non-empty, at least one of the certificates in the
certificate chain SHOULD be issued by one of the listed CAs.
Paragraph (version B):
If the "certificate_authorities" extension in the
CertificateRequest message was present, at least one of the
certificates in the certificate chain SHOULD be issued by one of
the listed CAs.
Paragraph (version A):
The server is permitted to request client authentication at any time
after the handshake has completed by sending a CertificateRequest
message.  The client SHOULD respond with the appropriate
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 may require 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 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):
A client that receives a CertificateRequest message without having
sent the "post_handshake_auth" extension MUST send an
"unexpected_message" fatal alert.
Paragraph (version B):
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).