On Thu, Feb 4, 2021 at 6:29 AM Eric Rescorla <e...@rtfm.com> wrote: > > > 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 > Though note that this is an external semantic to TLS for close_notify. It's not specified with that reqt. -Ekr 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
