On Fri, Mar 1, 2019 at 6:39 PM Nick Sullivan <nick= 40cloudflare....@dmarc.ietf.org> wrote:
> > > On Fri, Mar 1, 2019 at 6:27 PM Christopher Wood < > christopherwoo...@gmail.com> wrote: > >> On Fri, Mar 1, 2019 at 3:19 PM Mike Bishop <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 >> https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ > 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
