Subject: Re: [Emu] Review of draft-ietf-emu-eap-tls13

From: Bernard Aboba <[email-masked]>
Date: Mon, 8 Mar 2021 05:27:42 -0800

Alan --

Thanks for the very thorough review comments.

"Implementations should not make the same mistake with TLS 1.4 as was

done with TLS 1.3.  Therefore, this document should explicitly call
out this issue, and suggest a path for implementations to follow."

[BA] Agree, particularly given that other TLS changes could be coming
in future (e.g. post-quantum support).

"   The EAP-TLS
   server always commits to not send any more handshake messages by
   sending a TLS close_notify alert."

[BA] From the interop testing, it seems that application data is more
implementable.

"e.g. The "no peer authentication" situation MUST NOT be used to give
normal network access to EAP peers.  Instead, deployments SHOULD
provide access which is limited in both time, and in capability.
Usually this means a "quarantine" network, or "walled garden", which
has only limited capability.

Also, the Security Considerations section has no discussion of the
security impact of not authenticating the peer.  As Section 2.1.5 is
new, it has major impacts on security, and thus needs to be discussed."

[BA] Agree, especially due to security vulnerabilities that have
arisen in this area.

"NIT: the exporters were first defined in TLS 1.2, and have been widely
available in TLS library implementations.  Using master secret,
etc. has not been necessary for a while.  Further, the "non-standard"
use of Master Secret, etc. was first done in the original EAP-TLS RFC
[2716], in 1999.  The TLS WG later defined and stanardized the
exporters in order to meet the needs of EAP-TLS."

[BA] Agree. RFC 2716 defined the original TLS exporter, so calling it
"non-standard" is wrong.