There has been a lot of discussion on the ending of the handshake that I hope I have parsed. Here is my perspective as an client implementor (not an author):
1. I don't see a strict requirement for an authenticated signal at the end of the handshake. No prior version of EAP-TLS needed this and I don't necessarily see the need now. An EAP-TLS client should wait until it has satisfied all of its server validation policies and completes TLS before accepting a connection to the server, even if a "rogue" server starts sending EAP-Success all the time. Any client which blindly connects in this case is a broken client. 2. Although I don't see any security benefit, such a signal *may* be convenient to help EAP-TLS implementations update their state machines to support TLS 1.3. For example, if an EAP-TLS state machine previously used to assume that a "TLS complete" signal from its TLS library was sufficient to advance to a new state where it will no longer accept TLS payload might break when TLS 1.3 is used. Such a state machine would not necessarily know when to advance to this state with some similar sort of signal that the server is done. A different state machine which simply will always process TLS payload even after a "TLS complete" signal from its TLS library may not need any updates at all to work with TLS 1.3. I believe such a state machine would be able to handle a NewSessionTicket after TLS completion without issues even without a signal. Windows currently happens to fall into the first camp, where a signal is convenient. It seems to me that using close_notify is more semantically correct, but has some tradeoffs. A. In some cases, where the commitment message may be able to allow for a shorter handshake, using close_notify doesn't allow the client to send an alert, which is a non-starter in my opinion. B. If we settle for an extra round trip, we can use close_notify and make sure the client always has at least 1 chance to send an alert. This seems to me to be roughly where we started the discussion. Perhaps I have some of the theoretical details regarding the authenticated end signal incorrect as my perception is definitely colored by being mainly a client implementor. I happen to prefer the draft-13 commitment message because it seems to allow one less round trip in some cases. I'm happy to see discussion occurring either way and hope my perspective as an implementor is useful in driving toward a resolution. Jorge Vergara From: Emu <emu-boun...@ietf.org> On Behalf Of Joseph Salowey Sent: Monday, February 1, 2021 11:32 AM To: Alan DeKok <al...@deployingradius.com> Cc: <t...@ietf.org> <t...@ietf.org>; EMU WG <emu@ietf.org>; Benjamin Kaduk <ka...@mit.edu> Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT) On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok <al...@deployingradius.com<mailto:al...@deployingradius.com>> wrote: On Feb 1, 2021, at 11:26 AM, Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: > Yes, this is what I have in mind. So, maybe there's never any need for the > server to say "I won't say anything more" after just one round trip? I think so, yes. That means of course EAP-TLS will always require 4.5 round trips. [Joe] I don't follow why this means 4.5 round trips would be required. Alan DeKok. _______________________________________________ TLS mailing list t...@ietf.org<mailto:t...@ietf.org> https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=04%7C01%7Cjovergar%40microsoft.com%7Cd91c71b48e0c4b698fbc08d8c6e850bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637478048391997828%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y8w56%2BgJwrxEOi%2B%2FgFCeQpZnA8%2FjPqslXFEngbk8dKE%3D&reserved=0>
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
