On 10/9/2019 10:16 PM, Rob Sayre wrote: > On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla <e...@rtfm.com > <mailto: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.
If the Origin is identified by IP address, an observer on path between CDN and Origin just has to look at the IP address to find out whatever information was in the SNI. Do you have a specific threat in mind? It cannot be about just the CDN and the Origin server, because observers can easily assess whether CDN X serves origin O. Are you concerned that the observer will correlate incoming traffic from client to CDN with outgoing traffic from CDN to Origin? This is an issue common to pretty much every relay service. I understand that Tor has specific algorithms for dealing with that, involving for example insertion of delays at the relay points. Is that the kind of work that you have in mind? I am not sure that it would fit easily within the TLS charter, but there are other working groups... -- Christian Huitema
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
