On Feb 1, 2021, at 9:55 AM, Eric Rescorla <e...@rtfm.com> wrote: > 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.
That use of CloseNotify would be before the server receives the client certificates. It prevents the server from sending TLS alerts for certificate errors (expired, unknown CA, etc). That would be an unmitigated disaster for deployments. The CloseNotify *could* be sent after the server receives the client certs. But that still means another full round of EAP, before the final EAP-Success. So from that view, there's no difference between CloseNotify and an explicit commitment message. > 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. Except that if the server likes the client cert, Figure 1 of draft-13 shows the next packet is EAP-Success. So the client has no *authenticated* way of telling that it has been authenticated. Any party to the conversation could send a blank EAP-Success (which is 4 bytes of unauthenticated data). And thus break EAP-TLS. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
