Re: [TLS] Two Multi-CDN proposals

[Mike Bishop <[e-mail]>]

Totally agree that we want to avoid the extra DNS round-trip as often as possible.  However, I see the options in the opposite light – if all you need is #136, then you can put exact addresses into #137 and get the same behavior.  The question is whether the additional capabilities of #137 are safe and needed.  Depending how much later #137 is added, we may wind up needing to support both, which would be… suboptimal.

I think what will swing the needle on safety – how often there’s divergence – lies in how the record is positioned.  Two problems with the current approach that I see:

  *   Correct me if I’m wrong, but I don’t believe the alias is allowed to have subdomains.  If www.example.com<http://www.example.com> is a CNAME, then _esni.www.example.com cannot exist, can it?
  *   Even presuming that it did, or that it weren’t a subdomain, it would follow its own CNAME chain which might not lead to the correct provider.

If, however, the ESNIKeys RRType is resolved by following the CNAME from the host, it depends on how often two queries for two different RRTypes on the same hostname follow different CNAME chains.  We have a ready-made way to test that – A and AAAA.  I have an idea where we can get some data on that.

From: TLS <[e-mail]> On Behalf Of Eric Rescorla
Sent: Friday, March 1, 2019 7:19 PM
To: Nick Sullivan <nick=[e-mail]>
Cc: <[e-mail]> <[e-mail]>
Subject: Re: [TLS] Two Multi-CDN proposals


On Fri, Mar 1, 2019 at 6:39 PM Nick Sullivan <nick=[e-mail]<mailto:[e-mail]>> wrote:


On Fri, Mar 1, 2019 at 6:27 PM Christopher Wood <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, Mar 1, 2019 at 3:19 PM Mike Bishop <[e-mail]<mailto:[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.

Thanks for the summary, Chris.

Speaking for Cloudflare, we prefer the method described in #136 and would be willing to implement ESNI records this way.

I have sympathy for organizations with a preference for #137 for debuggability reasons, but I would rather avoid situations in which the client needs to do an additional DNS query if avoidable.

I would support the option to include either extension based on operator preference.

This more or less aligns with my views.

From my perspective, we know that #136 is safe, although it may be inconvenient for some operators, and it's not clear to me that #137 can be made to work without frequently incurring another serialized DNS query. If we had some evidence to the contrary, I would be somewhat more favorable to #137, though I would probably still prefer #136 for reasons of simplicity, especially as we can always add #137 later if it proves viable..

-Ekr



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

_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls