Re: [dns-privacy] [Ext] next steps for draft-opportunistic-adotq

On Wed, Mar 24, 2021 at 7:56 AM Jim Reid <jim@rfc1035.com> wrote:

>
>
> > On 24 Mar 2021, at 14:10, Bill Woodcock <woody@pch.net> wrote:
> >
> > How many mqps are necessary to have a voice in your vision of
> multistakeholderism?
>
> I don’t know.
>
> I think/hope we have the same vision of multistakeholderism. If not,
> that’s a conversation for another time and place.
>
> > Or, viewed from the other end of the spectrum, are you suggesting that
> only the two or three largest TLDs out of two thousand, count?
>
> No, of course not. Any TLD or authoritiev server is welcome to do whatever
> it wants here. Even if I think it’s a bad idea. Which could very well be an
> incentive for others to deploy.
>
> What I am saying is this WG needs to think more about the impacts* of
> Do[TH] on busy authoritative servers (not just TLDs). And maybe for busy
> recursive servers too. Some of us were talking about that just over an hour
> ago in the RIPE DNS WG:
>
>
> https://www.ripe.net/participate/ripe/wg/active-wg/dns/remote-sessions/2021-03-24-ripe-dns-wg-hollenbeck-balanced-dns-information-protection-strategy.pdf
>
> AFAICT the WG hasn’t yet considered any of the risk analysis issues
> identified in Scott’s presentation.
>

Right. I've read this and I think it's interesting but not really
dispositive. It seems to me that there are two arguments here:

- The combination of QMIN and aggregation/caching around the recursive
  decreases the need for TLS to the root and the TLD

- There are operational risks to running TLS on the root and TLD
  servers

WRT the first point, I don't think QMIN helps as much as you might
like for two reasons:

1. In a very large number of cases, it's the SLD which is sensitive.
   This means that QMIN at the TLD doesn't really help at all.
   And by extension, because you need to protect the NS record
   for the TLD (and they're not DNSSEC signed at the parent),
   not having TLS to the root means that you don't adequately
   protect the TLS connection to the TLD server either.

2. It's true that caching by the recursive helps some -- especially
   for large resolvers -- but there is still some information
   leakage if the cache is cold and you can observe both sides.
   Moreover, this just seems like an argument against ADoX entirely,
   because it applies as much to the connection to the SLD server.
   And given that ADoX is a charter item, it seems like there is a
   presumption that we should be working on this.

WRT the operational risk (slide 3), it's likely true that it's
somewhat harder to run a DoX server than a Do53 server. However, given
that we have plenty of worked examples of TLS servers of comparable if
not greater scale being operated with high reliability (e.g., Google,
Fastly, Cloudflare, etc.), I think there's pretty strong evidence that
this is an operational issue that can be addressed.

Of course, the IETF can't make the TLD servers run ADoX, but as
long as some TLDs are willing to, it seems odd not to specify it,
especially as the mechanisms are mostly the same at every level
of the hierarchy.

-Ekr

>
> * Those impacts BTW go beyond query rates or TLS session management.
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>