Draft: draft-ietf-emu-eap-tls13

Commentary: The PR only fixed some of  's comments . I updated the PR to address all  's comments that was copied in the issue 
 From  's review : 
 Also 
 Looks good to merge
Paragraph (version A):
In addition to the improved security and privacy offered by TLS 1.3,
there are other significant benefits of using EAP-TLS with TLS 1.3.
Privacy, which in EAP-TLS means that the peer username is not
disclosed, is mandatory and achieved without any additional round-
trips.  Revocation checking is mandatory and simplified with OCSP
stapling, and TLS 1.3 introduces more possibilities to reduce
fragmentation when compared to earlier versions of TLS.
Paragraph (version B):
In addition to the improved security and privacy offered by TLS 1.3,
there are other significant benefits of using EAP-TLS with TLS 1.3.
Privacy, which in EAP-TLS means that no information about the
underlying peer identity is disclosed, is mandatory and achieved
without any additional round-trips.  Revocation checking is mandatory
and simplified with OCSP stapling, and TLS 1.3 introduces more
possibilities to reduce fragmentation when compared to earlier
versions of TLS.
Paragraph (version A):
TLS 1.3 changes both the message flow and the handshake messages
compared to earlier versions of TLS.  Therefore, much of Section 2.1
of RFC5216 does not apply for TLS 1.3.
Paragraph (version B):
TLS 1.3 changes both the message flow and the handshake messages
compared to earlier versions of TLS.  Therefore, much of Section 2.1
of RFC5216 does not apply for TLS 1.3.  EAP-TLS 1.3 remains backwards
compatible with EAP-TLS 1.2 RFC5216 . TLS version negotiation is
handled by the TLS layer, and thus outside of the scope of EAP-TLS.
Therefore so long as the underlying TLS implementation correctly
implements TLS version negotiation, EAP-TLS will automatically
leverage that capability.
Paragraph (version A):
For TLS 1.3, resumption is described in Section 2.2 of RFC8446.  If
the client has received a NewSessionTicket message from the EAP-TLS
server, the client can use the PSK identity associated with the
ticket to negotiate the use of the associated PSK.  If the EAP-TLS
server accepts it, then the security context of the new connection is
tied to the original connection and the key derived from the initial
handshake is used to bootstrap the cryptographic state instead of a
full handshake.  It is up to the EAP-TLS peer to use resumption, but
it is RECOMMENDED that the EAP-TLS peer use resumption if it has a
valid ticket that has not been used before.  It is left to the EAP-
TLS server whether to accept resumption, but it is RECOMMENDED that
the EAP-TLS server accept resumption if the ticket which was issued
is still valid.  However, the EAP-TLS server MAY choose to require a
full handshake.  As in a full handshake, sending a NewSessionTicket
during resumption is optional.  As described in Appendix C.4 of
RFC8446, reuse of a ticket allows passive observers to correlate
different connections.  EAP-TLS peers and EAP-TLS servers SHOULD
follow the client tracking preventions in Appendix C.4 of RFC8446.
Paragraph (version B):
For TLS 1.3, resumption is described in Section 2.2 of RFC8446.  If
the client has received a NewSessionTicket message from the EAP-TLS
server, the client can use the PSK identity associated with the
ticket to negotiate the use of the associated PSK.  If the EAP-TLS
server accepts it, then the resumed session has been deemed to be
authenticated, and securely tied to the associated with the prior
authentication or resumption.  It is up to the EAP-TLS peer to use
resumption, but it is RECOMMENDED that the EAP-TLS peer use
resumption if it has a valid ticket that has not been used before.
It is left to the EAP-TLS server whether to accept resumption, but it
is RECOMMENDED that the EAP-TLS server accept resumption if the
ticket which was issued is still valid.  However, the EAP-TLS server
MAY choose to require a full handshake.  In the case a full handshake
is required, the negotiation proceeds as if the session was a new
authentication, and resumption had never been requested.  The
requirements of Sections section_auth and ticket then apply in their
entirety.  As described in Appendix C.4 of RFC8446, reuse of a ticket
allows passive observers to correlate different connections.  EAP-TLS
peers and EAP-TLS servers SHOULD follow the client tracking
preventions in Appendix C.4 of RFC8446.
Paragraph (version A):
By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
without having to extract the Main Secret, ClientHello.random, and
ServerHello.random in a non-standard way.
Paragraph (version B):
By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
which provides a public API for the exporter.  Note that EAP-TLS with
TLS 1.2 RFC5216 can be used with the TLS exporter since the public
exporter was defined in RFC5705.
Paragraph (version A):
There are a number of security issues related to resumption that are
not described in RFC5216.  The problems, guidelines, and requirements
in this section therefore applies to all version of TLS.
Paragraph (version B):
There are a number of security issues related to resumption that are
not described in RFC5216.  The problems, guidelines, and requirements
in this section therefore applies to EAP-TLS when it is used with any
version of TLS.