Re: [TLS] Two Multi-CDN proposals

[Christopher Wood <[e-mail]>]

On Fri, Mar 1, 2019 at 3:19 PM Mike Bishop <[e-mail]> wrote:
>
> Stephen, there are a couple complicating factors here where I think we all have varying knowledge gaps.
>
> There are two major ways of pointing to a CDN:  Direct A/AAAA records and CNAMEs.  The easiest way to handle key update complexities on the part of the CDN(s) is simply to CNAME the ESNI query for your domain to their ESNI record, but you can certainly directly host your CDN’s keys in your domain if you prefer.  Nothing should preclude that.
> The issue we’re trying to address is when the ESNI record and the A/AAAA record follow different CNAME chains and you get the records from different hosts.  Of course, if we move to an ESNI RRType with the same hostname (see #105), there’s hopefully a single CNAME chain that gets cached at the resolver and used when looking up both queries.  If they remain separate hostnames, it seems like it gets much easier for them to diverge.
> It’s my understanding that DNSsec doesn’t play well with returning a subset of all extant RRs for a given name+type.  However, some CDNs return DNS results tailored to the user’s location; the load-balancing servers will (in some cases) return CNAMEs to different targets based on the desired traffic share.  That’s not a behavior that maps well to DNSsec as I understand it.  You mention DNSsec signing your domain as part of why you have issues with the proposal, but I think this is an open issue beyond ESNI or these PRs.
>
> Maybe someone better-steeped in DNS/DNSsec can help us figure out how all that should work, and I agree with you that there are definitely bumps here we need to iron out – maybe those are just questions to answer, or maybe changes to the structure of the record are warranted.
>
> However, these PRs are primarily about what information should be in these records and how clients make use of it.  I disagree with you that we have to resolve both questions at the same time.  Let’s agree on content first, and spent some time separately with DNS folks to see whether the content can be more pleasantly arranged.

Thanks all for the discussion so far! Focusing strictly on the content
of the records and not the formatting, as Mike suggests, we
essentially have the following:

- #137 gives clients a way to detect A/AAAA+ESNI mismatch and recover,
at the cost of another sequential DNS query for ESNI. In this change,
A/AAAA records still control where traffic goes.
- #136 never requires clients to send a second DNS query for ESNI
since clients ignore the A/AAAA results. In this change, ESNI records
dictate routing.

With #137, clients willing to send a second DNS query will get ESNI
for all supporting providers. Clients unwilling to send a second DNS
query will only get ESNI for those providers which ensure that their
A/AAAA and ESNI records very rarely mismatch. With #136, clients only
get ESNI for those providers capable of building ESNI records with
correct addresses. In theory, these providers should be the same ones
that could ensure A/AAAA and ESNI record matching.

Given this, the discussion seems to hinge on the following question:
Are operators comfortable with the risks of letting ESNI records
control routing. If so, #136 is probably a better design for said
operators. If not, then #137 is probably required.

Note that this does not mean we must choose between #136 and #137
right now. We can do both (after possibly simplifying #137!), use
them, and see what works best in practice.

Anyway, I hope this summary accurately captures the differences and
possible tradeoffs.

Best,
Chris