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. > 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
