On Feb 1, 2021, at 11:09 AM, Eric Rescorla <e...@rtfm.com> wrote: > That's not what I'm proposing. I'm only talking about the case where the > server says this after flight (2).
OK, my misreading of the text. > Right. But close_notify is the message that more matches the TLS semantics. I agree. > Ignoring the protocol mechanics, let's just talk about what signals you think > the client ought to want to receive. The two I am aware of are: > > 1. From the server's perspective, the TLS handshake is complete. > 2. The server will not be sending any more handshake messages to the client. > > When client authentication is being used, then for obvious reasons (1) cannot > be delivered prior to the server receiving and processing the client's > certificate. Agreed? Yes. > Indeed, this seems like a problem with the flow shown in Figure 1, because > the server sends Commitment prior to reading the client's cert. Yes. > ISTM that the relevant question is when one might want to receive (2). In > particular, when would the client want to learn that the server will not send > any more handshake messages when the client has second flight handshake > messages still outstanding? Can you explain to me how this is useful? I'm just trying to summarize the discussion so far, and get clarification on exactly what we're trying to do. So take what I say with a grain of salt... I didn't write the text in the current draft. The main issue I can see where (2) might be useful is to deal with TLS 1.3's separation of "TLS finished" from other handshake messages. If the SessionTicket message comes *after* "TLS finished", then it might be in a separate EAP packet. The client doesn't know that there's an additional handshake until it receives that message. So an explicit CloseNotify sent by the server *after* receiving the client certificate would seem useful. It's an authenticated message saying "yes, I agree we're done". If the client cert has issues, the server can send TLS alerts *before* the CloseNotify. So the client has to either wait for those, OR an explicit CloseNotify, to see if it's (a) rejected, or (b) authenticated Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
