On Mon, Feb 1, 2021 at 8:22 AM Alan DeKok <al...@deployingradius.com> wrote:
> 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 > 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? -Ekr Alan DeKok. > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
