Re: [TLS] Two Multi-CDN proposals

[Eric Rescorla <[e-mail]>]

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
>