This is a new message to summarize history, requirements, etc. for EAP-TLS and TLS 1.3. The focus here is the requirements for EAP-TLS, and how the 0x00 commitment message versus CloseNotify meets those. I'll ignore the exporter changes here, as those are less controversial.
The original proposal in the EAP-TLS draft was to send a zero-length application data message in order to signal that no more post-handshake messages were needed. From the -05 version: When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by appending an empty application data record (i.e. a TLS record with TLSPlaintext.type = application_data and TLSPlaintext.length = 0) to the last handshake record. After sending an empty application data record, the EAP server may only send an EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. However, the OpenSSL APIs (among others) do not allow for sending zero octets of application data. The proposal was then changed to send a 0x00 octet. There was discussion that CloseNotify could achieve the same goals. But CloseNotify requires an additional round trip. There are strong opinions that additional round trips are bad. In addition, CloseNotify prevents the TLS layer from sending a TLS Fatal Alert: https://www.mail-archive.com/emu@ietf.org/msg03092.html i.e. there would be no TLS layer signalling for the following situations: bad_certificate, unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown, illegal_parameter, unknown_ca, access_denied, etc This limitation would be an unmitigated disaster for EAP-TLS. Those messages are required by people deploying EAP-TLS. Without those messages, it will be near impossible to debug configuration issues. As a result, we cannot use CloseNotify to signal "no more handshake messages" from the server. There is a related issue, in that TLS 1.3 separates Session Tickets from TLS handshakes. So it's still possible for the EAP state machine to send a 0x00 octet, and then the TLS state machines sends that *before* a Session Ticket. In addition, RFC 8446 Figure 1 shows that application data can be sent by the server to the client, *before* the client certificate is sent to the server. So sending this octet in EAP-TLS does not prove that the client certificate has been validated. DISCUSS: the EAP-TLS draft should explain that the 0x00 byte is NOT a positive signal of either "finished TLS", or "successful authentication". DISCUSS: the EAP-TLS draft should also explain that session tickets may be sent either before or after the 0x00 octet. Does the packet flow look any different for the two cases? If so, what does that mean? DISCUSS: We have interoperable implementations of -13. Does this mean that the EAP state machines *implicitly* work with the TLS state machines? There is no *explicit* requirement in the draft about ordering, and no discussion thereof. I suspect that this means the implementations work in part by accident, instead of by design. So updates to TLS libraries *may* break EAP-TLS. It would be best to make any assumptions explicit. And / or to recommend to implementors that they be flexible with respect to changing order of the 0x00 octet vs session tickets. In situations where resumption is not needed, figure 1 of https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13 is correct. There are 3.5 rounds, which is about as low as possible. Adding resumption here would *increase* there number of rounds to 4.5, which is worse! DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that this examples does not include Session Tickets. Section 2.1.2 should be updated to note that there are more rounds than for the previous section. In situations where the certificate chain is longer, the initial authentication will be >=4.5 round trips, and session tickets are perhaps more useful. DISCUSS: the EAP-TLS draft should be updated to better explain the costs / benefits of using resumption I hope that this summary clarifies the issues and requirements. The 0x00 octet is intended as a promise that no more handshake messages are sent. I leave it to others to discuss whether or not that promise is useful. As for what to do, my $0.02 is that the behaviour described in -13 is fine. The 0x00 octet is useful. The key exporters are perhaps odd, but not problematic. We have multiple inter-operable implementations. The remaining question is this: DISCUSS: other than word-smithing the above points, are there serious objections to the behaviour documented in -13? i.e. does the IETF want to recommend that EAP-TLS alpha testing begins *now*, or should it wait until 2022? The only advice I offer here is that we *cannot* rev EAP-TLS, as there is no "version" flag in the EAP-TLS header. See https://tools.ietf.org/html/rfc5216#section-3.1 So if we later discover that EAP-TLS is flawed, we can only deprecated EAP-TLS, and create a new EAP-TLS "prime", with a new EAP type code. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
