Re: [TLS] Two Multi-CDN proposals

[Nick Sullivan <[e-mail]>]

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.


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