On Wed, Jun 26, 2019 at 09:16:19PM -0700, Joseph Salowey wrote: > The Working Group last call has completed with no comments for > draft-ietf-emu-eap-tls13-05. I would like to confirm that some working > group members have reviewed the draft. If you have reviewed the draft > please respond to this thread.
While the current design may work in theory, the use of an "empty TLS record" looks problematic from implementation and deployment view point. That terms itself is quite a bit confusing term since this is not really talking about an empty TLS record in the EAP-TLS message, but about a zero length TLSPlaintext structure that gets encrypted into a _non_-zero length TLSCiphertext structure that gets encoded in the TLS record that goes over EAP-TLS (and that is not empty since all ciphers add something to the payload length in practice). The main problem here is that at least OpenSSL is not willing to send such an empty TLSPlaintext structure. SSL_write() has following to say about this: https://www.openssl.org/docs/man1.1.1/man3/SSL_write.html "You should not call SSL_write() with num=0, it will return an error. SSL_write_ex() can be called with num=0, but will not send application data to the peer." In other words, there does not seem to be any convenient way of implementing this with the current version of one of the most commonly used TLS libraries. I can make this work by sending out a one-octet (0x00) TLSPlaintext as a workaround, but it does not look like I could make the implementation comply with the draft without changing the TLS library which is close to a complete showstopper for quick deployment. It would seem to make sense to me to allow the EAP-TLS 1.3 server to send out either an empty plaintext or a one octet plaintext to avoid this issue in a straightforward manner. This is referring to the following areas in the draft (-05): 2.1.1. In the case where EAP-TLS with mutual authentication is successful, the conversation will appear as shown in Figure 1. The EAP server commits to not send any more handshake messages by sending an empty TLS record, see Section 2.5. (that confusing use of "empty TLS record" and "TLS empty record" in the message exchange figures) 2.5. 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. (this is where that TLSPlaintext.length = 0 should also allow 1 to make this easier to implement and deploy) -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
