Re: [TLS] Multi-CDN and ESNI

[Patrick McManus <[e-mail]>]

Definitely agree this is something that needs to be addressed..

As Mike notes, the fundamental issue is that there are 2 pieces of
information that are statefully related (the key and address) but obtained
statelessly from each other and can therefore come from un-coordinated
sources. 2 CDNs are commonly un-coordinated sources.. but I've seen this
with other kinds of cloud providers too. All of which should be target
audiences of ESNI (because they terminate a variety of hostnames on a
smaller number of addresses).

fwiw there is a muddled github issue open on this in the old
individual-draft repo:
https://github.com/ekr/draft-rescorla-tls-esni/issues/35 .. which I'll
re-open when the tls-wg repo starts being used for this draft.

I see three solution spaces.

1] As Rich suggests, you can coordinate the uncoordinated sources to have
one keying record to rule them all. I suspect that's actually not good for
anonymity unless it somehow had a normalized global set .. and given the
one way nature of a CNAME pointer, I feel like this would be really fragile.

2] you could scope the keys to only be valid for certain addresses by
putting the valid addresses in the key record. This wouldn't help you do
ESNI when they didn't match, but at least you could avoid hard failure. (or
you could ignore the addressing record but that might be a bridge too far?)

3] My preferred approach, you could scope the keys to the same intermediate
name. So if www.example.com -> cname www.cdn-a.com -> ESNI record
www.cdn-a.com we could make a rule that the ESNI record would only apply to
address records with a final intermediate of www.cdn-a.com. (I'm presuming
we'll shift from TXT to ESNI RRTYPE without a prefix, but I don't think it
matters for this..).. when there is a mismatch you could use the addressing
intermediate as a place to try a new ESNI query from.. That's a perf
penalty, but its only paid in the hopefully rare case where these things
are unsyncd.

#3 is admittedly a bit non traditional, but I spent a bit of time looking
at the features of DNS APIs that already have the necessary surface to make
a query for a new RRTYPE... and the cname intermediates are indeed
generally available.. its true of getdns, res_query, the IOS and MacOS
interfaces, DnsQuery* on windows, and of course the custom dns stacks in
cronet/android and firefox/doh could do it.

I hope to work this into a PR.. my first attempt wasn't very readable, but
I'll try again tomorrow.

-P






On Tue, Oct 23, 2018 at 1:59 PM Salz, Rich <[e-mail]> wrote:

> I think perhaps we need to take a step back and explain something that
> might not be well-known outside the community of CDN’s and their
> customers.  It is not uncommon for (admittedly larger) origins to use
> multiple CDN’s, and to switch among them. This can be done on a per-request
> basis, because of things like contractual arrangements that make one
> preferable, or it can be done globally but switched in a matter of seconds
> because of a short TTL on the www.example.com entry.
>
>
>
> The issues that Mike discusses impact on this, somewhat negatively.
>
>
>
> A quick hack thought is to allow multiple entries in the TXT record,
> forcing a wee bit more work on the CDN.
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>