Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt)

[Rob Sayre <[e-mail]>]

On Sat, Oct 12, 2019 at 12:11 AM Salz, Rich <[e-mail]> 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