On Feb 1, 2021, at 2:48 PM, Jorge Vergara <jover...@microsoft.com> wrote: > > 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
Prior versions *implicitly* relied on the server sending "TLS Finished" after the client certificate had been validated. > 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. We should ideally make the protocol robust to broken implementations. RFC 4137 was written to deal with implementations having these sort of issues in broken EAP state machines. > > 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. Yes. > 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. True, but that's a bit of a separate issue. > 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. I agree. > 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. Presuming that we *do* need an explicit signal, which I think is true. If we do need it, then the extra round trip is unavoidable. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
