Ok – so this issue was raised at IETF 102. (presentation https://www.ietf.org/proceedings/102/slides/slides-102-emu-eap-tls-with-tls-13-00)
Just reading the slides is not telling me what was the problem. I think I am going to need to hear the audio of the presentation. I have an extremely vague memory that there was an OpenSSL problem involved here but I would not swear to that. You might be a better description either from John Mattsson or Jouni. From: Mohit Sethi M <[email protected]> Sent: Friday, July 31, 2020 7:09 AM To: [email protected] Cc: Benjamin Kaduk <[email protected]>; Jim Schaad <[email protected]>; Eric Rescorla <[email protected]> Subject: Commitment Message handling in EAP-TLS 1.3 Dear all, Thanks all for the discussion on the commitment message. draft-ietf-emu-eap-tls13-10 (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10) in figure 2 shows the ticket establishment and commitment message: EAP Peer EAP Server EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=EAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, <-------- TLS Finished) EAP-Response/ EAP-Type=EAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=EAP-TLS (TLS NewSessionTicket, <-------- Commitment Message) EAP-Response/ EAP-Type=EAP-TLS --------> <-------- EAP-Success and the relevant text on commitment message: 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 sending a Commitment Message. The Commitment Message is a TLS record with application data 0x00 (i.e. a TLS record with TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00). Note that the length of the plaintext is greater than the corresponding TLSPlaintext.length due to the inclusion of TLSInnerPlaintext.type and any padding supplied by the sender. EAP server implementations MUST set TLSPlaintext.fragment to 0x00, but EAP peer implementations MUST accept any application data as a Commitment Message from the EAP server to not send any more handshake messages. The Commitment Message may be sent in the same EAP-Request as the last handshake record or in a separate EAP- Request. Sending the Commitment Message in a separate EAP-Request adds an additional round-trip, but may be necessary in TLS implementations that only implement a subset of TLS 1.3. I couldn't parse the comments about the "KeyUpdate" message. Perhaps having the discussion over email will help me understand the issue. --Mohit
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
