some thoughts after catching up on this thread: * cdn -> origin ime generally resolves via DNS for the same reason you want anything else to resolve via DNS: a level of indirection is handy for management. Occasionally it bypasses DNS for the same reasons you want anything to bypass DNS: a level of indirection adds tail risk and overhead.
* origins sometimes have reasonable potential for ESNI anonymity sets themselves .. cloud hosting environments would be good examples. this should be encouraged. * it seems pretty unusual that a CDN and Origin would share keys.. the major use case of the CDN key is to cover an anonymity set that is a significant number of distinct customers. * using one v6 per origin (when you've got multiple origins available) isn't a great pattern imo - not only does it make ESNI rather useless (with an anonymity set of 1). but it fails to leverage the handshake and congestion control amortizations across origins that h2/h3 can and will be able to give you. We've built all the necessary http authority muxxing stuff into higher levels with SNI and HTTP at this point, there's no need to force it back into correlations withe the transport addresses. * a few folks do like to authenticate the cdn to the origin with client certs. That's nifty - but overall its pretty unpopular for the same reasons managing distributed keys are always unpopular - its a hassle to manage in the wild certs in a low risk way. DNS (scoped to ESNI - not as authentication replacement) is a bit nicer in this respect because you don't need to manage all the clients (multi cdn), but rather just a origin property.. tldr; imo none of this works if the origin does not have a decent anonymity set potential. If it does, just reuse esni for that hop rather than minting something new. On Sat, Oct 12, 2019 at 3:19 AM Rob Sayre <say...@gmail.com> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
