Summary: The document says it defines EAP-TLS with TLS 1.3 (or higher). This is not true, and all references to "or higher" should be removed.
It allows for multiple session tickets, going against the recommendations of RFC 8446, and against the consensus from implementors. It implicitly permits session tickets to be sent before the client certificate has been validated. These tickets are useless, and serve only to bloat the packet exchange. It adds "no peer authentication", but is silent on the security considerations of that change. It claimes to be "backwards compatible" with earlier versions of EAP-TLS, but does not explain how that is achieved. It discusses HelloRetryRequest, with no explanation as to how that affects EAP-TLS. From a reading of the document and RFC 8446, it appears that it doesn't. It should be updated to suggest that resumption uses the same EAP Identity as from the first full authentication. This suggestion solves a number of potential privacy and interoperability issues. It defines key exporters for other TLS-based EAP methods. The WG already has a document which covers this topic, accepted as a WG document prior to these changes being added to this document. The IANA considerations section does not match the rest of the document. It defines key label prefixes, not key labels. Either the spec needs to be updated, or the IANA registry requirements needs to be updated. Preferably after consultation with the TLS WG. It leaves significant portions of the protocol as implementation-defined. Experience shows that implementation-defined behavior is the source of implementation problems, security issues, and interoperability issues. There has been significant push-back against adding implementation guidance to this specification. This push-back has had real-world costs. If the document is not corrected, there will be years of issues with interoperability, security, deployment, etc. These costs will be borne by the implementors, which is why they believe that updating the document is critical to the success of EAP-TLS 1.3. The hackathon showed that a number of the implementation decisions are not reflected in this document. Instead, the information has been shared in "out of band" discussions between the various implementors. This out of band process is appropriate for discussions before a standard has been finalized. However, it is not appropriate to expect that new implementors obtain guidance through secret "back room" processes. Instead, this document should contain sufficient information to allow everyone to implement EAP-TLS in an interoperable manner. The purpose of an engineering specification is to build something. If the specification is not sufficiently detailed to build things, then the specification is wrong. There should be zero resistance to making sure that the specification is clear, correct, and useful. As a result, the document has a large number of major issues which affect security, implementation, standards compliance, and IANA. The document is not ready for publication until these issues have been resolved. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
