Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Alan DeKok <[e-mail]>]

On Feb 1, 2021, at 2:48 PM, Jorge Vergara <[e-mail]> 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.