On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok <al...@deployingradius.com> wrote:
> 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 agree that extra round trips are bad, I'd like to take a step back here and think about what this message is trying to do. Here's the relevant text: TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post- Handshake messages use the handshake content type and can be sent after the main handshake. One such Post-Handshake message is NewSessionTicket. The NewSessionTicket can be used for resumption. After sending TLS Finished, the EAP-TLS server may send any number of Post-Handshake messages in separate EAP-Requests. The relevant question is when the server knows what post-handshake messages it will send. There are two points at which the server might wish to send post-handshake messages: 1. After the server's first flight. 2. After the client's second flight. Let's take the second case first. If the server is sending (or potentially sending) post-handshake messages after the client's second flight (e.g., after reading its certificate), then it can easily send a close_notify after sending all of them. This will appear in the same flight as the commitment message would have (because you can't send it before the post-handshake messages) and avoid the need for an extra round trip. The first case, where the commitment message is sent in 0.5-RTT, is the interesting one. However, the server has no more information after sending SFIN than it does sending EE, so I believe that the easiest way to deal with this is with a TLS extension that says "I do not send any post-handshake messages". This would still leave the server free to send any relevant alerts in response to the client's second flight. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
