On Thu, Feb 4, 2021 at 12:57 AM John Mattsson <john.matts...@ericsson.com> wrote:
> Hi, > > > > I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS > interact better is a very promising idea. This would probably take some > time to get specified and implemented so it is probably a future > optimization/simplification rather that something EAP-TLS 1.3 should wait > for. > > > > An extension that "I do not send any post-handshake messages" would work > and remove the need for a commitment message. > > > > ------------------------------------ > > NoPostHandShake Extension > > ------------------------------------ > > > > Clients MAY send this extension in ClientHello. It contains no data. > > > > Servers MAY send this extension in EncryptedExtentions. It contains no > data. > > > > When the "NoPostHandShake" extension is negotiated, the server MUST NOT > send any post handshake messages. > > > > ------------------------------------- > > > > However, this would also stop the client from doing resumption which is > also very important. EAP-TLS fragments TLS into a large number of > round-trips, and database lookup to authorize clients is often slow, so > resumption is essential to get good performance. > > > > The current Post-Handshake NewSessionTicket is not well-suited for EAP-TLS > as is introduces the demand for the commitment message as well as > introducing an extra round-trip. > I don't really understand what EAP needs here, but it seems to me that the commitment message (or the close_notify) is serving two purposes: 1. Saying that the handshake completed successfully 2. Saying that there will be no more messages I understand from the discussion that knowing that there will be no more messages is useful. Do you think that the client knowing that the handshake completed is unnecessary? -Ekr
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu