On Wed, Oct 9, 2019 at 10:16 PM Rob Sayre <say...@gmail.com> wrote: > On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla <e...@rtfm.com> wrote: > >> >>> I don't think that's quite what I'm proposing. I'm proposing >>> (optionally) sending the SNI with a client certificate. >>> >> >> What are you trying to accomplish by doing that? >> > > I want to keep the SNI encrypted in TLS hops that use client certificates, > but where ESNI won't work. > > For example, how is the SNI transmitted in the parens here: > > [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin ] > > I don't think a DNS-based solution like ESNI will work for that second > hop, because the origin tends to be identified by an IP address rather than > a domain name. >
I feel like we're perhaps talking past each other, so I'm going to start back at the beginning. In the ordinary case of Client -> Origin or Client -> CDN, the SNI principally serves to tell the server which origin the client wants and thus which certificate to serve. For this reason, it has to go in the CH. In the case of CDN -> Origin, it seems like SNI could serve the same purpose (say that the origin server is hosting multiple servers), in which case it seems like the same requirements apply. OTOH, if the origin server just hosts one origin, then you could potentially have the SNI delivered later (as you suggest), but then why have SNI delivered at all? What am I missing? -Ekr > thanks, > Rob >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
