Subject: [dns-privacy] Root Server Operators Statement on DNS Encryption

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 30 Mar 2021 14:49:26 +0000

This is worth reading:

https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf

Scott

---

From: Rob Sayre <[email-masked]>
Date: Tue, 30 Mar 2021 17:00:29 -0700

> https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf

I am not sure I agree it is worth reading.

Why can't "The Root Server Operators" run QUIC etc as well as their
existing UDP methods?

thanks,
Rob

---

From: Erik Kline <[email-masked]>
Date: Tue, 30 Mar 2021 17:08:14 -0700

> Why can't "The Root Server Operators" run QUIC etc as well as their

(no hats)

>From my reading the answer, and the whole document, seems to be
summarizable in this one excerpt:

    "Root Server Operators do not feel comfortable being the early adopters
of authoritative DNS encryption and would like to first see increased
deployment in other parts of the DNS hierarchy."

Seems fair to me, for the time being.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 30 Mar 2021 17:19:29 -0700

On Tue, Mar 30, 2021 at 5:08 PM Erik Kline <[email-masked]> wrote:

>     "Root Server Operators do not feel comfortable being the early
> adopters of authoritative DNS encryption and would like to first see
> increased deployment in other parts of the DNS hierarchy."
>

So, as the document says, "attention turns toward providing privacy
protection for the next step: recursive resolvers to authoritative
servers". Which part of the hierarchy should move next, then?

> Seems fair to me, for the time being.

The DNSSEC stuff stood out to me. Why is that even seen as something that
would help?

thanks,
Rob

---

From: Jim Reid <[email-masked]>
Date: Wed, 31 Mar 2021 01:19:50 +0100

> On 31 Mar 2021, at 01:08, Erik Kline <[email-masked]> wrote:
> 
>     "Root Server Operators do not feel comfortable being the early adopters of authoritative DNS encryption and would like to first see increased deployment in other parts of the DNS hierarchy."
> 

+1. Core DNS infrastructure such as the root simply should not be the crash test dummy for anything. That’s just basic common sense.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Mar 2021 17:24:41 -0700

> Seems fair to me, for the time being.

As I said earlier, this seems overly conservative given our experience with
large scale TLS-based services.

With that said, this doesn't seem to me to present a severe problem: there
are a relatively small number of TLD servers, so we could probably create a
lookaside list of which ones support TLS as suggested in
draft-rescorla-dprive-adox-latest-00 Section 3,

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Mar 2021 01:33:28 +0100

Hiya,

> large scale TLS-based services.

For the root servers, I don't get why QNAME minimisation
isn't enough? If it is enough, that'd imply to me that the
root server operators statement is fine, so long as it
is only read to apply to root servers and not TLDs.

> draft-rescorla-dprive-adox-latest-00 Section 3,

I agree that the privacy issues with TLD servers are more
worthy of attention and I guess require encryption if we are
to improve things. I'm not saying the above draft is a good
way to handle that, but the problem in querying TLDs is real,
whereas for root servers it seems to me way less of a deal.

Or... am I confused? (That happens often:-)

Cheers,
S.

---

From: Erik Kline <[email-masked]>
Date: Tue, 30 Mar 2021 17:53:59 -0700

> is only read to apply to root servers and not TLDs.

I had to think about this for a bit, because I didn't properly appreciate
that before.

I think, "IN NS com." doesn't reveal much information.  But perhaps "IN NS
sensitive-tld." could have privacy implications for some folks?

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Mar 2021 18:17:18 -0700

> Or... am I confused? (That happens often:-)

As Erik indicates, it's possible that the the TLD is sensitive, though it's
a bit hard to evaluate that risk.

However, recall that the TLS connection to the parent is what protects the
NS records for the child, as they are not DNSSEC signed. Thus, one has a
somewhat fragile situation if one has to store a lookaside list of the TLS
status (and at some level the nameservers!) for the TLDs. I'm not saying
it's unmanageable, but it's not amazing.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Mar 2021 02:36:46 +0100

Hiya,

On 31/03/2021 01:53, Erik Kline wrote:
> I think, "IN NS com." doesn't reveal much information.

Right. And such cases are probably a huge percentage of
both all, and all-of-the-sensitive, queries to root
servers.

> But perhaps "IN NS sensitive-tld." could have privacy implications
> for some folks?

I guess that's a fair point that querying some e.g. ccTLD
NS from some locales could sometimes be an issue. Do we
have any information as to the prevalence of such? (Or of
cases where such queries are abused in ways that decrease
privacy or enforce censorship.)

Maybe in addition to recommending QNAME minimisation it'd
be good if root server operators also recommended services
that face such issues deploy those services lower down in
the naming hierarchy? My guess is that service providers
will do that anyway but no harm to give a bit of direction.

On 31/03/2021 02:17, Eric Rescorla wrote:
> 
> However, recall that the TLS connection to the parent is what
> protects the NS records for the child, as they are not DNSSEC signed.
> Thus, one has a somewhat fragile situation if one has to store a
> lookaside list of the TLS status (and at some level the nameservers!)
> for the TLDs. I'm not saying it's unmanageable, but it's not
> amazing.

Also fair. Requiring the parent to be involved is a big deal
for any of the offered solutions here (regardless of whether
or not DNSSEC is involved).

In any case, I still think we ought be able to live with a
situation where the root server operators do less than the
TLD server operators - it's the queries to the latter that
more or less have to include the vast majority of sensitive
information. (And if a solution that works for .com is found,
then I bet we'd be able to find something that works as well
for root server operators.)

Cheers,
S.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 30 Mar 2021 18:56:09 -0700

> or not DNSSEC is involved).

I don't think anyone expects any high-traffic piece of DNS infrastructure
to just flip a switch and enable TLS or equivalent.

But, I also think it's increasingly untenable to claim a server can serve
traffic at all, unless it can support TLS 1.3 or something similar.

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Mar 2021 03:27:24 +0100

> traffic at all, unless it can support TLS 1.3 or something similar.

I don't really disagree, but in the case of SMTP/TLS afaik
some of the major service providers had to discover that
themselves before they believed it, and I can well imagine
the kind of reluctance that might exist within the set of
people who have to keep stuff working. A switch from Do53
to DoT or DoH is also arguably a bigger change so I'm not
too surprised that there are cold feet that may need to be
encouraged to approach the source of warmth:-)

Cheers,
S.

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 31 Mar 2021 10:44:08 +0200

On 31/03/2021 02.53, Erik Kline wrote:
> I think, "IN NS com." doesn't reveal much information.  But perhaps 
> "IN NS sensitive-tld." could have privacy implications for some folks?

Yes, it could be e.g. accidentally leaked garbage.  But even so, it's 
not so difficult to completely avoid querying root servers, through one 
of the "local root" approaches.  It's certainly way easier that any ADoT 
stuff.  And I haven't noticed real interest in encryption towards root; 
TLDs are another matter.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 31 Mar 2021 11:12:38 +0200

On Tue, Mar 30, 2021 at 05:00:29PM -0700,
 Rob Sayre <[email-masked]> wrote 

> Why can't "The Root Server Operators" run QUIC etc as well as their

Just a note that DNS-over-QUIC is far from standard
currently. <https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/>
Unlike Dot and DoH.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 31 Mar 2021 11:15:30 +0200

On Tue, Mar 30, 2021 at 05:19:29PM -0700,
 Rob Sayre <[email-masked]> wrote 

> The DNSSEC stuff stood out to me. Why is that even seen as something that

Because one of the ways to improve privacy at the root is local
synthesis of answers by the resolver, following RFC 8198, and it
depends of DNSSEC. (Otherwise, we could just use RFC 8020.)

True, it will work only for non-existing domains, which may not be too
revealing but it is just one of the recommended ways, the other being
QNAME minimisation (which does not depend on DNSSEC).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 31 Mar 2021 11:22:16 +0200

On Tue, Mar 30, 2021 at 05:53:59PM -0700,
 Erik Kline <[email-masked]> wrote 

> "IN NS sensitive-tld." could have privacy implications for some

ir? cu? gay?

Also, while com/NS will be in the resolver's cache most of the time,
some small TLDs won't, so the request may be more easily correlated
with other activity.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 31 Mar 2021 11:24:49 +0200

On Wed, Mar 31, 2021 at 10:44:08AM +0200,
 Vladimír Čunát <[email-masked]> wrote 
 a message of 12 lines which said:

> it's not so difficult to completely avoid querying root servers,
> through one of the "local root" approaches.

RFC 8806 does not seem mentioned in the statement. Does anyone know
why?

---

From: Brian Haberman <[email-masked]>
Date: Wed, 31 Mar 2021 08:33:58 -0400

> RFC 8806 does not seem mentioned in the statement. Does anyone know

I was wondering the same thing. 8806 would definitely preclude the need
to support encryption at the root.

Brian

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 31 Mar 2021 09:45:35 -0300

> sensitive-tld." could have privacy implications for some folks?

This suppose that tracking the subsequent TLS connection to the TLD
auth server would not reveal that "secret"...

---

From: Jim Reid <[email-masked]>
Date: Wed, 31 Mar 2021 13:52:28 +0100

> On 31 Mar 2021, at 13:33, Brian Haberman <[email-masked]> wrote:
> 

This is one of the things that puzzles me about the current discussion. The WG seems to be pushing TLS-based solutions and ignoring/dismissing other options. For instance RFC8806 or QNAME minimisation may well yield good enough privacy outcomes with fewer moving parts or operational impacts. We’d know these trade-offs if the WG was willing to do a threat model and/or risk analysis to provide more clarity about what problem(s) need solving.

We all want better privacy of course. For some definition of privacy. But what does that actually mean in the context of queries to authoritative servers at the root or TLDs? And is TLS the *only* game in town?

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Mar 2021 13:58:09 +0100

Hiya,

On 31/03/2021 13:52, Jim Reid wrote:

> We all want better privacy of course. For some definition of privacy.
> But what does that actually mean in the context of queries to
> authoritative servers at the root or TLDs? 

Workable answers for the root and TLDs are likely very
different, as the scale of risk is very different.

I think it doesn't really help to try discuss both root
servers and TLDs at the same time.

> And is TLS the*only*  game
> in town?
When encrypting DNS based on some standard protocol? It is,
though of course you can have that DoT or DoH or DoQ or maybe
even opaquely flavoured;-(

Cheers,
S.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 31 Mar 2021 13:00:43 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Stephen
> Farrell
> Sent: Wednesday, March 31, 2021 8:58 AM
> To: Jim Reid <[email-masked]>; Brian Haberman
> <[email-masked]>
> Cc: [email-masked]
> Subject: [EXTERNAL] Re: [dns-privacy] Root Server Operators Statement on
> DNS Encryption
>
>
> Hiya,
>
> Workable answers for the root and TLDs are likely very different, as the scale
> of risk is very different.
>
> I think it doesn't really help to try discuss both root servers and TLDs at the
> same time.
>
> When encrypting DNS based on some standard protocol? It is, though of
> course you can have that DoT or DoH or DoQ or maybe even opaquely
> flavoured;-(

[SAH] Why assume that encryption is required to provide confidentiality?

Scott

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 31 Mar 2021 15:05:34 +0200

On Wed, Mar 31, 2021 at 01:00:43PM +0000,
 Hollenbeck, Scott <shollenbeck=[email-masked]> wrote 

> [SAH] Why assume that encryption is required to provide confidentiality?

We never assumed that. RFC 7626 (the threat model and problem analysis
that some people claim is missing) is clear (section 2.5.2 for
instance).

---

From: Jim Reid <[email-masked]>
Date: Wed, 31 Mar 2021 14:12:03 +0100

> On 31 Mar 2021, at 13:58, Stephen Farrell <[email-masked]> wrote:
> 
>> And is TLS the *only* game in town?

> When encrypting DNS based on some standard protocol? It is

I know that Stephen. The point I was trying (and apparently failing) to make was there are other privacy-friendly tools/protocols available that could well be good enough solutions for some parts of the problem space.

As an example, widespread adoption of RFC8806 - no sniggering at the back! - could obviate the need for encrypted queries to the root or possibly offload the TLS goop to the local instances of the root. But the WG doesn’t seem to want to consider that.

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 31 Mar 2021 15:15:14 +0200

> As an example, widespread adoption of RFC8806 - no sniggering at the back! - could obviate the need for encrypted queries to the root or possibly offload the TLS goop to the local instances of the…

So far I haven't noticed anyone pushing for encryption to the root.  (I 
believe ZONEMD will kill that need completely once deployed.)

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Mar 2021 14:15:33 +0100

> [SAH] Why assume that encryption is required to provide confidentiality?

I didn't make that assumption.

S.

> 
> Scott
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Mar 2021 14:20:12 +0100

Hiya,

On 31/03/2021 14:12, Jim Reid wrote:
> I know that Stephen. The point I was trying (and apparently failing)
> to make was there are other privacy-friendly tools/protocols
> available that could well be good enough solutions for some parts of
> the problem space.
> 
> As an example, widespread adoption of RFC8806 - no sniggering at the
> back! - could obviate the need for encrypted queries to the root or
> possibly offload the TLS goop to the local instances of the root. But
> the WG doesn’t seem to want to consider that.

Not sure how you reach that conclusion TBH. ISTM that that
is actively being discussed.

It seems pretty obvious thought that while such mechanisms
can certainly help for root servers, there is going to be a
need for a TLS-based mechanism if TLDs want significantly
better privacy. I reckon that's the case even if traffic from
large recursives isn't considered sensitive - there'll I
guess always be many smaller recursives where queries are
going to be sensitive. (What's not yet clear is whether we
can define a TLS-based mechanism that's good enough to get
widely deployed by TLDs.)

Cheers,
S.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 31 Mar 2021 15:21:42 +0200

On Wed, Mar 31, 2021 at 03:15:14PM +0200,
 Vladimír Čunát <[email-masked]> wrote 
 a message of 11 lines which said:

> So far I haven't noticed anyone pushing for encryption to the root.

Indeed. And this is why the root server operators statement is
surprising. It looks like a reply to some pressure to encrypt,
pressure that I saw nowhere.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 31 Mar 2021 15:23:22 +0200

On Wed, Mar 31, 2021 at 02:12:03PM +0100,
 Jim Reid <[email-masked]> wrote 
 a message of 15 lines which said:

> But the WG doesn’t seem to want to consider that.

But what DPRIVE could do here? RFC 8806 is published. Besides sending
its successor on the standards track, what do you suggest the group to
do?

---

From: Jim Reid <[email-masked]>
Date: Wed, 31 Mar 2021 14:32:46 +0100

> On 31 Mar 2021, at 14:05, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> RFC 7626 (the threat model and problem analysis

Stephane, RFC7626 is 6 years old. It predates the DoH and DoT (and soon DoQ) specs. Some other risks have changed since 2015 too.

It’s not your fault that fine RFC has been OBE. :-)

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Mar 2021 14:40:48 +0100

Hi Jim,

On 31/03/2021 14:32, Jim Reid wrote:
>> RFC 7626 (the threat model and problem analysis that some people
>> claim is missing) is clear (section 2.5.2 for instance).
> 
> Stephane, RFC7626 is 6 years old. It predates the DoH and DoT (and
> soon DoQ) specs. 

RFC7626 was IMO quite important in enabling those later
protocols, so that age and sequence are signs of success.

> Some other risks have changed since 2015 too.
> 

I'm not sure what point you're making there tbh, but I
don't believe 7626 is OBE when it comes to considering
privacy issues arising from interactions between recursives
and TLDs, which is a big part of what we're discussing
here I hope.

Cheers,
S.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 31 Mar 2021 09:54:39 -0400

> and TLDs, which is a big part of what we're discussing

And 7626bis is in the RFC Editor's queue...

Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 31 Mar 2021 09:57:04 -0400

> its successor on the standards track, what do you suggest the group to

That would be a first step. Does anyone have an idea of how widely used
8806 is today?

We would also need to determine the best way to advertise 8806, or its
successor, as part of the overall DNS privacy solution.

Brian

---

From: Rob Sayre <[email-masked]>
Date: Wed, 31 Mar 2021 12:55:14 -0700

> currently. <https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/>

Probably telling that I meant DoH over QUIC. Sorry to be unclear. :)

I still don't understand the resistance here. Some data on what the impact
would be still seems like the most helpful thing to move the conversation
forward. The query volumes in question look big, but not that big, so I
think using existing TLS technologies seems like the best path unless that
can be shown to be impractical. The linked PDF basically says "we don't
want to", without providing much in the way of justification.

thanks,
Rob

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 31 Mar 2021 22:29:23 +0200

> On Mar 31, 2021, at 9:55 PM, Rob Sayre <[email-masked]> wrote:
> I still don't understand the resistance here. Some data on what the impact would be still seems like the most helpful thing to move the conversation forward.

We have that:

https://vaibhavbajpai.com/documents/papers/proceedings/dot-pam-2021.pdf

Short story is that it’s 3x - 15x higher load on the servers, more delay, fewer people served, easier DDoS.

That’s a price that can be paid, if there’s a suitably corresponding benefit, and no more effective way to solve the problem.

Could you state the problem that’s being solved?

                               -Bill

---

From: Rob Sayre <[email-masked]>
Date: Wed, 31 Mar 2021 13:51:38 -0700

On Wed, Mar 31, 2021 at 1:29 PM Bill Woodcock <[email-masked]> wrote:

> > I still don't understand the resistance here. Some data on what the
> impact would be still seems like the most helpful thing to move the
> conversation forward.
>
> We have that:
>

That paper is about home measurements, and says:

"Previous work [8,17,26] has studied the support and response times of DoT
(and DoH). However, the studies performed response time measurements from
proxy networks and data centers, which means that results might not
appropriately reflect the latency of regular home users..." and only
measures DoT, rather than the more popular DoH.

> Could you state the problem that’s being solved?

Sure, it's in the first sentence of
https://tools.ietf.org/html/draft-ietf-dprive-opportunistic-adotq-00:

"A recursive resolver using traditional DNS over port 53 may wish instead
to use encrypted communication with authoritative servers in order to limit
passive snooping of its DNS traffic."

thanks,
Rob

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 31 Mar 2021 23:15:53 +0200

> On Mar 31, 2021, at 10:51 PM, Rob Sayre <[email-masked]> wrote:
> 
> 
> 
> "Previous work [8,17,26] has studied the support and response times of DoT (and DoH). However, the studies performed response time measurements from proxy networks and data centers, which means that results might not appropriately reflect the latency of regular home users...”

…and it’s measuring latency rather than server-side load.  I just checked with our engineers, and it sounds like the server load per-query is more like 3x-5x higher for the encrypted queries.

> only measures DoT, rather than the more popular DoH.

DoH isn’t that much worse than DoT from a load perspective, but it's a web-browser thing…  It’s difficult for me to imagine anyone with enough clue to operate a recursive resolver wanting to use DoH to query an authoritative server.  What would be the point?

> Sure, it's in the first sentence of https://tools.ietf.org/html/draft-ietf-dprive-opportunistic-adotq-00:
> 
> "A recursive resolver using traditional DNS over port 53 may wish instead to use encrypted communication with authoritative servers in order to limit passive snooping of its DNS traffic."

Right, so that just means the wording of the draft is over-broad, in that it just says “authoritative” rather than “authoritative SLD” or something.  It’s quite a stretch to think that anything sensitive would be disclosed between a well-behaved recursive and a _root_ server, since it doesn’t disclose either the individual nor the domain being queried.

So, again, what problem would be solved?

                                -Bill

---

From: Rob Sayre <[email-masked]>
Date: Wed, 31 Mar 2021 14:28:13 -0700

On Wed, Mar 31, 2021 at 2:16 PM Bill Woodcock <[email-masked]> wrote:

>
> …and it’s measuring latency rather than server-side load.  I just checked
> with our engineers, and it sounds like the server load per-query is more
> like 3x-5x higher for the encrypted queries.
>

Plenty of folks have evaluated the costs here. I'd prefer to discuss data
rather than "checking with engineers". It's not really reasonable to
measure "server load per-query" without a bunch of other data on how the
TLS sessions are being created and maintained.

So, if you have some data you'd like to share with the list, that would be
most welcome.

> DoH isn’t that much worse than DoT from a load perspective, but it's a
> web-browser thing…  It’s difficult for me to imagine anyone with enough
> clue to operate a recursive resolver wanting to use DoH to query an
> authoritative server.  What would be the point?
>

I think the idea is roughly that DoT/DoQ will just reinvent what's in DoH,
but without as much support and reuse. Here's Mozilla's latest numbers on
DoH:
https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-https-doh-update-recent-testing-results-and-next-steps/
(yes, it's latency)

> > "A recursive resolver using traditional DNS over port 53 may wish
> instead to use encrypted communication with authoritative servers in order
> to limit passive snooping of its DNS traffic."
>
> Right, so that just means the wording of the draft is over-broad, in that
> it just says “authoritative” rather than “authoritative SLD” or something.
> It’s quite a stretch to think that anything sensitive would be disclosed
> between a well-behaved recursive and a _root_ server, since it doesn’t
> disclose either the individual nor the domain being queried.
>

In that case, I think the goal would be to prevent aggregate measurements,
rather than individual data.

thanks,
Rob

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 31 Mar 2021 23:34:42 +0200

> On Mar 31, 2021, at 11:28 PM, Rob Sayre <[email-masked]> wrote:
> Plenty of folks have evaluated the costs here.

And in all cases, they’re non-negative.  Which is the point.

> In that case, I think the goal would be to prevent aggregate measurements, rather than individual data.

Moving the goalposts.

So you’re saying that we all need to go spend some non-negative number, which, for us, is 3x-5x as much, in order that third parties should not know the relative volume of recursor cache-misses with respect to different TLDs?

Why is this something I would want to spend my money to achieve, when there are problems that aren’t hypothetical, and for which there are real live constituents, on which I could spend the money instead?

                                -Bill

---

From: Rob Sayre <[email-masked]>
Date: Wed, 31 Mar 2021 14:39:14 -0700

On Wed, Mar 31, 2021 at 2:34 PM Bill Woodcock <[email-masked]> wrote:

> So you’re saying that we all need to go spend some non-negative number,
> which, for us, is 3x-5x as much, in order that third parties should not
> know the relative volume of recursor cache-misses with respect to different
> TLDs?
>
> Why is this something I would want to spend my money to achieve, when
> there are problems that aren’t hypothetical, and for which there are real
> live constituents, on which I could spend the money instead?
>

I think it's fine if you don't want to implement any given IETF RFC. Plenty
of other businesses have found the cost of encryption to be negligible on
modern networking stacks, especially for long-lived TLS connections.

Your business might be different--you know best there.

thanks,
Rob

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 31 Mar 2021 23:43:57 +0200

> On Mar 31, 2021, at 11:39 PM, Rob Sayre <[email-masked]> wrote:
> 
> I think it's fine if you don't want to implement any given IETF RFC.

Then those RFCs should be worded carefully so that they don’t suggest that the thing they’re proposing is generally applicable.  Particularly to the roots.  Which are actual critical infrastructure.

> Your business might be different--you know best there.

Since when are root servers a “business?”

We’re talking about critical infrastructure that everyone depends on.  Not some random person’s “business” that can fail or not fail.  This isn’t a place for pointless thrashing around as a byproduct of someone’s unrelated agenda.  Which was, I think, the point of the statement.

                                -Bill

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Mar 2021 22:49:12 +0100

Hiya,

On 31/03/2021 22:43, Bill Woodcock wrote:
> Then those RFCs should be worded carefully so that they don’t suggest
> that the thing they’re proposing is generally applicable.
> Particularly to the roots.  Which are actual critical
> infrastructure.
There was a load of mail earlier today on just that.

The real issue IMO is not querying the root servers but
the TLDs. There are still performance issues to consider
of course but the business model and the value to the
person somewhere behind the recursive are quite different.

I really wish we could stop all mixing up the roots with
the TLDs in this discussion.

Cheers,
S.

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 31 Mar 2021 23:51:09 +0200

> On Mar 31, 2021, at 11:49 PM, Stephen Farrell <[email-masked]> wrote:

Yep, exactly.

                                -Bill

---

From: Rob Sayre <[email-masked]>
Date: Wed, 31 Mar 2021 14:51:52 -0700

On Wed, Mar 31, 2021 at 2:44 PM Bill Woodcock <[email-masked]> wrote:

> Then those RFCs should be worded carefully so that they don’t suggest that
> the thing they’re proposing is generally applicable.  Particularly to the
> roots.  Which are actual critical infrastructure.
>

I think the IETF as a whole would get consensus on that issue.

> Since when are root servers a “business?”

Look, this is just needlessly combative. There are plenty of senses of the
word that don't mean what you are implying here.

>
> We’re talking about critical infrastructure that everyone depends on.  Not
> some random person’s “business” that can fail or not fail.  This isn’t a
> place for pointless thrashing around as a byproduct of someone’s unrelated
> agenda.  Which was, I think, the point of the statement.
>

Plenty of people come to the IETF from different perspectives. I don't
consider DNSSEC to be critical, but I know some people do. That doesn't
upset me, or force me to implement it.

thanks,
Rob

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 31 Mar 2021 23:57:41 +0200

> On Mar 31, 2021, at 11:51 PM, Rob Sayre <[email-masked]> wrote:
> Look, this is just needlessly combative.

Ok.  I was under the impression that you disagreed with the root server operators, and believed that they should implement encryption.

If that’s not something you feel like fighting about, I certainly don’t have any reason to want to.

                                -Bill

---

From: Andrew Campling <[email-masked]>
Date: Wed, 31 Mar 2021 22:12:52 +0000

On 31/03/2021 22:49, Stephen Farrell <[email-masked]> wrote:

>> Particularly to the roots.  Which are actual critical infrastructure.

I thought that the Root Server Operators Statement on DNS Encryption helped clarify a particular lack of interest from that group.  It made me wonder whether there has been any dialogue with TLD operators to establish whether they are interested in adopting encryption, as well as to understand the operational challenges that may need to be overcome to make any proposed solutions deployable?  

My apologies if the stance of TLD operators is well known to most in this group, however some of the recent debate on the list seems to suggest that the position of TLD operators is unclear.  To echo and extend a point made in a different post, what is the problem being solved, do sufficient TLD operators believe that it needs to be solved and is the proposed solution one that they are likely to deploy?  

Andrew

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 1 Apr 2021 00:23:26 +0200

> On Apr 1, 2021, at 12:12 AM, Andrew Campling <[email-masked]> wrote:
> It made me wonder whether there has been any dialogue with TLD operators to establish whether they are interested in adopting encryption?
> Some of the recent debate on the list seems to suggest that the position of TLD operators is unclear.

To my observation, the position of TLD operators is split.  Some of those who directly face the costs of implementation would like to defer and minimize those costs, and are asking people to be very clear what benefit those increased costs would bring, and whether other less costly methods have already been thoroughly explored.  Those who don’t directly face the costs of implementation are, generally, quite supportive of encryption.

                                -Bill

---

From: Andrew Campling <[email-masked]>
Date: Wed, 31 Mar 2021 22:32:48 +0000

-----Original Message-----
From: Bill Woodcock <[email-masked]> 
Sent: 31 March 2021 23:23
To: Andrew Campling <[email-masked]>
Cc: Stephen Farrell <[email-masked]>; Rob Sayre <[email-masked]>; [email-masked]
Subject: Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

> To my observation, the position of TLD operators is split.  Some of those who directly face the costs of implementation would like to defer and minimize those costs, and are asking people to be ver…

Any view on the proportion of TLD operators in each group?  

Andrew

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 1 Apr 2021 00:38:48 +0200

> On Apr 1, 2021, at 12:32 AM, Andrew Campling <[email-masked]> wrote:

I honestly don’t…  The numbers that have specifically weighed in are small, and for the vast majority of them, it’ll depend completely on the pricing model of commercial DNS operators they depend on.  And that, in turn, leads back to the question of whether the cost difference is getting passed through or not.

Sorry not to have anything more useful.

                                -Bill

---

From: Christian Huitema <[email-masked]>
Date: Wed, 31 Mar 2021 22:43:40 -0700

On 3/31/2021 2:15 PM, Bill Woodcock wrote:
>> "Previous work [8,17,26] has studied the support and response times of 
DoT (and DoH). However, the studies performed response time measurements from proxy networks and data centers, which means that results might not appropriately reflect the latency of regular home users...”
> …and it’s measuring latency rather than server-side load.  I just checked with our engineers, and it sounds like the server load 
per-query is more like 3x-5x higher for the encrypted queries.

I think that's the big motivation behind DoQ. Because QUIC runs over 
UDP, it makes some things easier than TCP. In particular, I have seen 
(and done) demos of supporting 50,000 QUIC connections over a single UDP 
socket, which is definitely easier on the system than trying to support 
parallel wait on 50,000 TCP sockets. But this is a motivation to do work 
on the subject, not a recommendation to change the way root servers 
operate. I personally agree with the statement that root servers should 
not rush to implement, but rather wait and see until the technology matures.

-- Christian Huitema

---

From: Rob Sayre <[email-masked]>
Date: Wed, 31 Mar 2021 22:51:49 -0700

On Wed, Mar 31, 2021 at 10:43 PM Christian Huitema <[email-masked]>
wrote:

> I think that's the big motivation behind DoQ. Because QUIC runs over UDP,
> it makes some things easier than TCP. In particular, I have seen (and done)
> demos of supporting 50,000 QUIC connections over a single UDP socket, which
> is definitely easier on the system than trying to support parallel wait on
> 50,000 TCP sockets. But this is a motivation to do work on the subject, not
> a recommendation to change the way root servers operate. I personally agree
> with the statement that root servers should not rush to implement, but
> rather wait and see until the technology matures.
>

I don't know... shouldn't they start work now?

I wonder if root server capex costs have gone down 41% since this post:
https://blog.verisign.com/domain-names/chromiums-reduction-of-root-dns-traffic/

thanks,
Rob