2019年3月3日(日) 5:57 Eric Rescorla <e...@rtfm.com>: > > > > On Fri, Mar 1, 2019 at 11:03 PM Mike Bishop <mbis...@evequefou.be> wrote: >> >> 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. > > > Sure, but if the error rate is too high, then people will just not do ESNI > with the non-exact address version, so you've absorbed complexity for nothing. > > i'd also like to hear from CDNs about whether their address ranges are really > small enough to not make the list of ranges prohobitive. > > >> 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 actually don't think that's so bad. The complexity of the union of 136 and > 137 isn't actually much more than the complexity of 137, especially if the > client just omits step 1 of the 137 algorithm (for exact addresses). > >> 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 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. > > > My understanding is that there was consensus to remove _esni, just that we > didn't get around to it because of this issue. > >> >> >> 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. > > > Great. I would be interested in seeing that.
FWIW, I am also looking forward to seeing the data, because if the chances of responses getting out-of-sync is very low (e.g. 0.1%), I think there's chance we might agree without having neither of #136 or #137. We could just use the ESNI key synchronization mechanism that was introduced in #124 by using IP address-based certificates. That'd have 2 RT penalty (or 1 RT when TCP fast open is used), but that might be tolerable if the probability is low. > > -Ekr > >> >> >> 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> 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 -- Kazuho Oku _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
