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

[Eric Rescorla <[e-mail]>]

On Mon, Feb 1, 2021 at 8:22 AM Alan DeKok <[e-mail]> wrote:

> On Feb 1, 2021, at 11:09 AM, Eric Rescorla <[e-mail]> 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.
>
>