On Sat, Oct 12, 2019 at 12:11 AM Salz, Rich <rs...@akamai.com> wrote:
> > > - How does a request of the form "username.example.com > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__username.example.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ujs6Lkbc_IGTiuLdcDk8syhWP1v9lNpztl9OxZuCvas&s=hBGHuzwfs66lIYRw2lkpneJu72vkeC9m5HH46EJ0i3c&e=>" > get through a CDN to an Origin while leaving the SNI encrypted on the wire? > > > > The CDN needs to see the decrypted SNI. > Agreed. > If the CDN and origin share the ESNI keys, the CDN can just pass the > original ESNI value along. If the CDN and origin do not share ESNI keys, > then the CDN will have to re-encrypt. If that is an issue you haven’t > explained why or I missed. > It's definitely one approach. I am not sure which keys should be used for the CDN -> Origin traffic, though. I suggested sending the SNI with the client cert, because it seemed simpler if client certs are already being used (an option I recommend for CDN -> Origin traffic). EKR's Host header suggestion may also be viable, but my goal is actually to make some TLS-level decisions about traffic based on the SNI. EKR's proposal also assumes some level of Host header / SNI divergence is allowed by the Origin host. These policies are not clear to me. For example, I'm not sure what rules a Cloudflare to Google Cloud Platform link would need to follow (this is a common enough setup that they have an egress agreement). > > - I also disagree with the argument that ESNI is pointless when “IPv6 > uniquely identifies the origin”. > > > > Can you explain why? > I agree that a unique IPv6 address would expose the fact that a CDN is communicating with an Origin, but I also think subdomain data could be used for tracking, and so the SNI should still be encrypted. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
