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.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
