Re: [TLS] Two Multi-CDN proposals

[Kazuho Oku <[e-mail]>]

2019年3月3日(日) 5:57 Eric Rescorla <[e-mail]>:
>
>
>
> On Fri, Mar 1, 2019 at 11:03 PM Mike Bishop <[e-mail]> 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 <[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]> wrote:
>>
>>
>>
>>
>>
>> On Fri, Mar 1, 2019 at 6:27 PM Christopher Wood <[e-mail]> wrote:
>>
>> On Fri, Mar 1, 2019 at 3:19 PM Mike Bishop <[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]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
Kazuho Oku