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

[Rob Sayre]

On Wed, Mar 31, 2021 at 10:43 PM Christian Huitema 
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
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Christian Huitema]

On 3/31/2021 2:15 PM, Bill Woodcock wrote:

We have that:

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


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

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Bill Woodcock]

> On Apr 1, 2021, at 12:32 AM, Andrew Campling  
> wrote:
>> On 31 March, 2021, at 23:223, Bill Woodcock  wrote:
>> 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.
> Any view on the proportion of TLD operators in each group?

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



signature.asc
Description: Message signed with OpenPGP
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Andrew Campling]

-Original Message-
From: Bill Woodcock  
Sent: 31 March 2021 23:23
To: Andrew Campling 
Cc: Stephen Farrell ; Rob Sayre ; 
dpr...@ietf.org
Subject: Re: [dns-privacy] Root Server Operators Statement on DNS Encryption


On 31 March, 2021, at 23:223, Bill Woodcock  wrote:
> On Apr 1, 2021, at 12:12 AM, Andrew Campling  
> 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.

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

Andrew 
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Bill Woodcock]

> On Apr 1, 2021, at 12:12 AM, Andrew Campling  
> 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



signature.asc
Description: Message signed with OpenPGP
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Andrew Campling]

On 31/03/2021 22:49, Stephen Farrell  wrote:

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

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 
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Bill Woodcock]

> On Mar 31, 2021, at 11:51 PM, Rob Sayre  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



signature.asc
Description: Message signed with OpenPGP
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Rob Sayre]

On Wed, Mar 31, 2021 at 2:44 PM Bill Woodcock  wrote:

> > On Mar 31, 2021, at 11:39 PM, Rob Sayre  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.
>

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


> > Your business might be different--you know best there.
>
> 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
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Bill Woodcock]

> On Mar 31, 2021, at 11:49 PM, Stephen Farrell  
> wrote:
> 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.

Yep, exactly.

-Bill



signature.asc
Description: Message signed with OpenPGP
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Stephen Farrell]

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.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Bill Woodcock]

> On Mar 31, 2021, at 11:39 PM, Rob Sayre  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



signature.asc
Description: Message signed with OpenPGP
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Rob Sayre]

On Wed, Mar 31, 2021 at 2:34 PM Bill Woodcock  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
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Bill Woodcock]

> On Mar 31, 2021, at 11:28 PM, Rob Sayre  wrote:
> Plenty of folks have evaluated the costs here.

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

 >> 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."
>>> 
>> 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?
>> 
> 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



signature.asc
Description: Message signed with OpenPGP
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Rob Sayre]

On Wed, Mar 31, 2021 at 2:16 PM Bill Woodcock  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.


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

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)


>
> >> 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."
>
> 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?
>

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

thanks,
Rob
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Bill Woodcock]

> On Mar 31, 2021, at 10:51 PM, Rob Sayre  wrote:
> 
> 
> 
> On Wed, Mar 31, 2021 at 1:29 PM Bill Woodcock  wrote:
> 
> 
>>> > On Mar 31, 2021, at 9:55 PM, Rob Sayre  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
>> 
> 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 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?

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

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



signature.asc
Description: Message signed with OpenPGP
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Rob Sayre]

On Wed, Mar 31, 2021 at 1:29 PM Bill Woodcock  wrote:

>
>
> > On Mar 31, 2021, at 9:55 PM, Rob Sayre  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


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
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Bill Woodcock]

> On Mar 31, 2021, at 9:55 PM, Rob Sayre  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



signature.asc
Description: Message signed with OpenPGP
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Rob Sayre]

On Wed, Mar 31, 2021 at 2:13 AM Stephane Bortzmeyer 
wrote:

> On Tue, Mar 30, 2021 at 05:00:29PM -0700,
>  Rob Sayre  wrote
>  a message of 56 lines which said:
>
> > Why can't "The Root Server Operators" run QUIC etc as well as their
> > existing UDP methods?
>
> Just a note that DNS-over-QUIC is far from standard
> currently. 
> Unlike Dot and DoH.
>

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
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Brian Haberman]

On 3/31/21 9:23 AM, Stephane Bortzmeyer wrote:
> On Wed, Mar 31, 2021 at 02:12:03PM +0100,
>  Jim Reid  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?

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



OpenPGP_signature
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Brian Haberman]

On 3/31/21 9:40 AM, Stephen Farrell wrote:
> 
> Hi Jim,
> 
> On 31/03/2021 14:32, Jim Reid wrote:
>>
>>
>>> On 31 Mar 2021, at 14:05, Stephane Bortzmeyer 
>>> 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.
>>
>> It’s not your fault that fine RFC has been OBE. :-)
> 
> 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.

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

Brian



OpenPGP_signature
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Stephen Farrell]

Hi Jim,

On 31/03/2021 14:32, Jim Reid wrote:




On 31 Mar 2021, at 14:05, Stephane Bortzmeyer 
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.

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


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.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Jim Reid]

> On 31 Mar 2021, at 14:05, Stephane Bortzmeyer  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. Some other risks have changed since 2015 too.

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

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Stephane Bortzmeyer]

On Wed, Mar 31, 2021 at 02:12:03PM +0100,
 Jim Reid  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?

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Stephane Bortzmeyer]

On Wed, Mar 31, 2021 at 03:15:14PM +0200,
 Vladimír Čunát  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.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Stephen Farrell]

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.




OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Stephen Farrell]

On 31/03/2021 14:00, Hollenbeck, Scott wrote:

-Original Message-
From: dns-privacy  On Behalf Of Stephen
Farrell
Sent: Wednesday, March 31, 2021 8:58 AM
To: Jim Reid ; Brian Haberman

Cc: dns-privacy@ietf.org
Subject: [EXTERNAL] Re: [dns-privacy] Root Server Operators Statement on
DNS Encryption


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


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


I didn't make that assumption.

S.



Scott
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Vladimír Čunát]

On 31/03/2021 15.12, Jim Reid wrote:

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.


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



___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Jim Reid]

> On 31 Mar 2021, at 13:58, Stephen Farrell  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.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Stephane Bortzmeyer]

On Wed, Mar 31, 2021 at 01:00:43PM +,
 Hollenbeck, Scott  wrote 
 a message of 38 lines which said:

> [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).

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Hollenbeck, Scott]

> -Original Message-
> From: dns-privacy  On Behalf Of Stephen
> Farrell
> Sent: Wednesday, March 31, 2021 8:58 AM
> To: Jim Reid ; Brian Haberman
> 
> Cc: dns-privacy@ietf.org
> Subject: [EXTERNAL] Re: [dns-privacy] Root Server Operators Statement on
> DNS Encryption
>
>
> 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;-(

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

Scott
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Stephen Farrell]

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.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Jim Reid]

> On 31 Mar 2021, at 13:33, Brian Haberman  wrote:
> 
> I was wondering the same thing. 8806 would definitely preclude the need
> to support encryption at the root.

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?

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Frederico A C Neves]

On Tue, Mar 30, 2021 at 05:53:59PM -0700, Erik Kline wrote:
> On Tue, Mar 30, 2021 at 5:33 PM Stephen Farrell 
> wrote:
> 
> >
> > Hiya,
> >
> > On 31/03/2021 01:24, Eric Rescorla wrote:
> > > As I said earlier, this seems overly conservative given our experience
> > with
> > > 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.
> >
> 
> 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?

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

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Brian Haberman]

On 3/31/21 5:24 AM, Stephane Bortzmeyer wrote:
> On Wed, Mar 31, 2021 at 10:44:08AM +0200,
>  Vladimír Čunát  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? 

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

Brian



OpenPGP_signature
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Stephane Bortzmeyer]

On Wed, Mar 31, 2021 at 10:44:08AM +0200,
 Vladimír Čunát  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? 

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Stephane Bortzmeyer]

On Tue, Mar 30, 2021 at 05:53:59PM -0700,
 Erik Kline  wrote 
 a message of 111 lines which said:

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

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.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Stephane Bortzmeyer]

On Tue, Mar 30, 2021 at 05:19:29PM -0700,
 Rob Sayre  wrote 
 a message of 69 lines which said:

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

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

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Stephane Bortzmeyer]

On Tue, Mar 30, 2021 at 05:00:29PM -0700,
 Rob Sayre  wrote 
 a message of 56 lines which said:

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

Just a note that DNS-over-QUIC is far from standard
currently. 
Unlike Dot and DoH.


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Vladimír Čunát]

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.



___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy