Normally, virtual-hosted TLS servers are known to a client by their domain name, and the client uses DNS to find an IP address corresponding to this domain name. The ESNI drafts are largely written in reference to this configuration.
I think Rob is describing the case where a TLS client is contacting a virtual-hosted origin that is defined by an IP address and an X.509 Common Name, but for which it does not have a domain name. In this case, reading ESNI public keys out of the DNS is not an option, because there is no domain name to look up. This situation does seem to be reasonably common for connections where the client is a CDN, and the server is an origin backend. (In that case, the domain name may exist, but its IP address and ESNI keys will be the CDN's, not the backend's.) The obvious solution is for the TLS client (i.e. the CDN) to support direct entry of ESNI public keys alongside the IP address. Users who want to be able to rotate their ESNI keys more easily should use a backend identified by a domain name that is distinct from the user-facing origin hostname. I don't think there's any need to couple SNI encryption to use of client certificates, nor is there any need to alter the ESNI protocol. On Thu, Oct 10, 2019 at 3:00 PM 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. > > thanks, > Rob > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
