From: Eric Rescorla <e...@rtfm.com> Date: Thursday, 4 February 2021 at 15:32 To: John Mattsson <john.matts...@ericsson.com> Cc: EMU WG <emu@ietf.org>, Benjamin Kaduk <ka...@mit.edu>, "t...@ietf.org" <t...@ietf.org> Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Thu, Feb 4, 2021 at 6:29 AM Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: On Thu, Feb 4, 2021 at 12:57 AM John Mattsson <john.matts...@ericsson.com<mailto: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. [John] Yes. It would also be on external semantic if an application data commit message is used. 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 [John] Before this last explosion of discussion, the only publicly discussed purpose of the commitment message was to my knowledge 2. All versions of the EAP-TLS 1.3 drafts from -01 to -14 was written with only 2. in mind. Recently people has also been brought up that also 1. is needed. My understanding is that this is not required by EAP in general, but it is required for secure interaction with 802.11. After writing this mail suggesting extensions, I invested more time to read the mail Bernard recently sent and all the references in detail. https://mailarchive.ietf.org/arch/msg/emu/hawPjEH2RRin4MlzqJe57Yrf0bQ/ After reading up on the 802.11 interaction, it seems to me that the possibility to do 1. is required in at least some deployments. I think the EMU WG need to discuss and agree on this. If 1. is always needed, any TLS extensions would not be needed.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
