On Fri, Oct 11, 2019 at 1:45 AM Eric Rescorla <e...@rtfm.com> wrote: > > OK, I think we've now reached where we are talking past each other. > > At a very high level, here's the TLS 1.3 handshake: > > C->S: CH (w/ SNI) > S->C: SH, CERT, CV, FIN > C->S: [CERT, CV], FIN > > In order for the server to send the certificate, which, as you can see, is > in its first flight, it has to have the SNI available. >
I think this is the disconnect. The situation you describe is common (sharing an IPv4 address), and I definitely understand why the SNI needs to be in the ClientHello in that situation. > This means that it has to go in the client's first flight. But the > client's certificate is in the client's second flight. And the client has > to have the server's certificate before it sends its certificate, because > otherwise it can't authenticate the server and so an active attacker can > get the client's cert. > > If you still disagree, maybe you could show me the ladder diagram you have > in mind? > The ladder diagram I have in mind is exactly as described in the TLS 1.3 RFC. Assume that the server can't send application data on its first flight, and that the client must send a certificate on its second flight. Then, assume that useful data can be transmitted in subdomain labels to a server that has issued a wildcard certificate. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
