On Fri, Oct 11, 2019 at 8:24 PM Eric Rescorla <e...@rtfm.com> wrote: > > > On Thu, Oct 10, 2019 at 8:12 PM Rob Sayre <say...@gmail.com> wrote: > >> On Fri, Oct 11, 2019 at 5:37 AM Martin Thomson <m...@lowentropy.net> wrote: >> >>> On Fri, Oct 11, 2019, at 07:57, Ben Schwartz wrote: >>> > 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 was about to say the same thing. No need to get fancy. >>> >> >> Isn't that more complicated than sending the SNI in the second client >> message, though? >> > > Well, both of these are more complicated than Host header. What's wrong > with that? >
The SNI and the host header often have to match (or at least have a known mapping), because the origin server might want to prevent domain fronting. This might be less of an issue over IPv6, but I think that's the reason the two fields are currently more tightly-coupled than they were originally. This issue has turned out to be surprisingly subtle, and current practices seem to vary widely. My goal is to keep the SNI encrypted on the wire from CDN to Origin (I understand that the SNI is visible to the CDN). thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
