On Mon, Feb 1, 2021 at 7:42 AM Alan DeKok <al...@deployingradius.com> wrote:
> On Feb 1, 2021, at 9:55 AM, Eric Rescorla <e...@rtfm.com> wrote: > > Let's take the second case first. If the server is sending (or > > potentially sending) post-handshake messages after the client's second > > flight (e.g., after reading its certificate), then it can easily send > > a close_notify after sending all of them. This will appear in the same > > flight as the commitment message would have (because you can't send it > > before the post-handshake messages) and avoid the need for an extra > > round trip. > > That use of CloseNotify would be before the server receives the client > certificates. It prevents the server from sending TLS alerts for > certificate errors (expired, unknown CA, etc). That would be an > unmitigated disaster for deployments. > That's not what I'm proposing. I'm only talking about the case where the server says this after flight (2). The CloseNotify *could* be sent after the server receives the client > certs. But that still means another full round of EAP, before the final > EAP-Success. So from that view, there's no difference between CloseNotify > and an explicit commitment message. > Right. But close_notify is the message that more matches the TLS semantics. > > The first case, where the commitment message is sent in 0.5-RTT, > > is the interesting one. However, the server has no more information > > after sending SFIN than it does sending EE, so I believe that the > > easiest way to deal with this is with a TLS extension that says > > "I do not send any post-handshake messages". This would still > > leave the server free to send any relevant alerts in response to > > the client's second flight. > > Except that if the server likes the client cert, Figure 1 of draft-13 > shows the next packet is EAP-Success. So the client has no *authenticated* > way of telling that it has been authenticated. Any party to the > conversation could send a blank EAP-Success (which is 4 bytes of > unauthenticated data). And thus break EAP-TLS. > I fear we are talking past each other. 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? 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. 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? -Ekr > Alan DeKok. > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
