I was discussing this offline with Jorge, who noticed that in TLS, alerts are SHOULD and not MUST:
https://tools.ietf.org/html/rfc8446#section-2 A failure of the handshake or other protocol error triggers the termination of the connection, optionally preceded by an alert message (Section 6). https://tools.ietf.org/html/rfc8446#section-6.2 Whenever an implementation encounters a fatal error condition, it SHOULD send an appropriate fatal alert and MUST close the connection without sending or receiving any additional data. In practice, these alerts have been seen almost all o f the time with TLS <1.3. In order for deployments to have useful error messages, I suggest updating draft-ietf-emu-eap-tls13 Section 2.1.4: ... Figures 5, 6, and 7 illustrate message flows in several cases where the EAP-TLS peer or EAP-TLS server sends a TLS fatal alert message. In earlier versions of TLS, error alerts could be warnings or fatal. In TLS 1.3, error alerts are always fatal and the only alerts sent at warning level are "close_notify" and "user_cancelled", both of which indicate that the connection is not going to continue normally, see [RFC8446]. ... new text: Note that [RCC 8446] Section 6.2 suggests that TLS alerts are optional: Whenever an implementation encounters a fatal error condition, it SHOULD send an appropriate fatal alert and MUST close the connection without sending or receiving any additional data. For EAP-TLS, we strengthen this requirement. EAP-TLS peers and EAP-TLS servers MUST send TLS alerts on TLS error conditions as diagrammed in Figures 5, 6, and 7. Failure to send TLS alerts means that the peer or server would have no way of determining what went wrong. And therefore administrators would have no way of determining how to fix deployment or configuration errors. Experience with existing implementations of EAP-TLS shows that TLS alerts are sent almost always, by both EAP-TLS peer and EAP-TLS server. So while this requirement is new for EAP-TLS 1.3, it should impose no additional burden on implementations/ Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
