On Thu, Oct 10, 2019 at 11:59 AM Rob Sayre <say...@gmail.com> wrote: > 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. >
What are you anticipating the server would do with the SNI? Ordinarily we expect the host header to be used for host identification purposes. -Ekr > thanks, > Rob >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
