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 <tls-boun...@ietf.org> On Behalf Of Eric Rescorla Sent: Friday, March 1, 2019 7:19 PM To: Nick Sullivan <nick=40cloudflare....@dmarc.ietf.org> Cc: <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] Two Multi-CDN proposals On Fri, Mar 1, 2019 at 6:39 PM Nick Sullivan <nick=40cloudflare....@dmarc.ietf.org<mailto:40cloudflare....@dmarc.ietf.org>> wrote: On Fri, Mar 1, 2019 at 6:27 PM Christopher Wood <christopherwoo...@gmail.com<mailto:christopherwoo...@gmail.com>> wrote: On Fri, Mar 1, 2019 at 3:19 PM Mike Bishop <mbis...@evequefou.be<mailto:mbis...@evequefou.be>> 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 TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
