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 <rs...@akamai.com> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
