Subject: Re: [dns-privacy] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10

From: Hugo Connery <[email-masked]>
Date: Sat, 1 Dec 2018 13:41:23 +0100

Hi Karl and list,

No and Yes.

The introduction section says "out of scope" not "there are
different attack vectors and operational concerns".

... and then I got to thinking.  (sorry about that)

But, I do agree that there are differences between the types
of attackers for recursers and authoritatives based on the
different outcomes of complete loss of service.

Recursive resolvers serve a wide variety of stub resolvers
over varying operating systems from some network(s), which the
operator gets to choose, but the resolvers need to be within those
network(s).  Some companies choose to offer recursive resolvers
that serve the entire internet (8.8.8.8, 1.1.1.1 etc.), but these
are currently the tiniest minority of recursive resolvers (*),
though this is likely to change with "recurser as a service".
The consequence of total failure of these resolver services for
the community within those network(s) is "the internet does
not work" (for them).

So, a recursive operator chooses which community (via networks)
they serve, must be amongst those networks, and the consequence
of loss of service is "the internet does not work" for clients
within those networks.

An authoritative server is different.  It does not get to choose
its community.  Ostensibly it is serving recursive resolvers (**),
but they could be anywhere, so this amounts to serving the
global internet.  But, the authoritative servers can be in any
reachable network.  The consequence of loss of all authoritative
resolvers for a collection of zones is that the services described
in its zones become increasingly globally unavailable as caches
of its records expire.

So, an authoritative operator must serve the entire internet,
can be anywhere, and the loss of service is "these sites dont
work" progressively for everybody.

>From this we can see who is motivated to attack what.  By attack
I mean limit or completely prevent service delivery by
non-military actors.

Notably, recursive resolvers that serve networks that are
limited geographically to a nation state have no defence
against the government of that nation state, but authoritatives
can skip around to avoid government attacks (aka laws).

Many governments and corporations attack recursors for censorship
purposes with political and/or cultural motives (see "Pirate Bay").
Authoritative regimes may wish to remove all (public) recursors
to create an internet blackout, but this is countered by (*)
above so they have to prevent access to the globally reachable
resolvers too (see "Great Firewall").

Authoritative resolvers may be attacked by extortionists for
money or miscreants for fame (see DDOS), or by competitors of
services described in the zone(s) for competitive advantage (see
"this is never published/I've got a furtive imagination").

So, yes the threat landscape is different because the consequences
of loss of service are different.

Note that adding encryption or session based query services
for authoritatives changes none of this and is countered by
money (more CPU/RAM etc.).  Obviously, authoritative operators
are legitimately motivated to minimize this burden (and should
carefully review proposed changes so that no new attacks methods
are admitted by new standards).

One of the defences for authoritatives is to prioritise serving
recursive resolvers, as they are their legitimate clientele (**).

One can identify recursive resolvers because they will honour
your TTL values and will be a sparse collection of addresses
within network(s).  This is not a perfect protection because
recursers can "go rogue" (cracked) or deliberately behave nicely
for a while (planned attack), but it should help with DDOS type
attacks that are not well planned.  Similarly, you can grade
your deliberate refusal of service to network(s) when under attack
from them.  Refuse service to all not already known recursers
for a while before refusing service to the entire network(s)
if the initial service restriction doesn't help.  But, if that's
the case, you have a good idea who is attacking you from those
network(s).

Regards,

  Hugo Connery

On Fri, 2018-11-30 at 19:13 +0000, Henderson, Karl wrote:
> Hi Paul,
> 
> The attack vectors and operational concerns are different for communication between the recursive-to-authoritative than for communication between the stub-to-recursive. For instance, a stub will
> typically communicate with one or two recursive resolvers while recursive resolvers may communicate with many authoritative resolvers - thus changing the nature of persistent TLS connections for
> this communication path.
> 
> The authors of [RFC8310] recognized this difference and highlight it in the Introduction section with this statement:
> 
> "The proposals here might be adapted or extended in future to be used for recursive clients and authoritative servers, but this application was out of scope for the DNS PRIVate Exchange (dprive)
> Working Group charter at the time this document was published."
> 
> Regards,
> Karl
> 
> On 11/30/18, 12:34 PM, "Paul Wouters" <[email-masked]> wrote:
> 
>     On Fri, 30 Nov 2018, Hollenbeck, Scott wrote:
>     
>     >> times have changed, and it deserves another look, but some note that says
>     >> "If running out of resources, drop the encryption and serve DNS data in
>     >> the clear might be needed". Ideally in a way that querying clients that
>     >> want to insist on privacy can bail out instead of receiving cleartext.
>     >
>     > Possibly, but it may also be worth discussing how to avoid getting into resource exhaustion situations in the first place. Do you have any thoughts on Karl's "need for a profile of encryption
> standards" comment?
>     
>     I am not sure I see a need for a different TLS/DTLS profile compared to
>     regular (web) based (D)TLS connections. What do you or Karl think would
>     be different?
>     
>     Paul
>     
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
-- 

Hugo Connery, Head of IT, DTU Environment

"There is no cloud, only other people's computers".  FSF

---

From: Lanlan Pan <[email-masked]>
Date: Mon, 3 Dec 2018 11:13:14 +0700

> can skip around to avoid government attacks (aka laws).
recursive should send less sensitive data to authoritative servers.

> recursive resolvers, as they are their legitimate clientele (**).
yes,  authoritative can caculate a trust level  to the query clients, to
prior serve the "truely" recursive resolvers, which is learned from the
query log.

> > The attack vectors and operational concerns are different for
> communication between the recursive-to-authoritative than for communication
> between the stub-to-recursive. For instance, a stub will
> > typically communicate with one or two recursive resolvers while
> recursive resolvers may communicate with many authoritative resolvers -
> thus changing the nature of persistent TLS connections for
> > this communication path.
> >
> > The authors of [RFC8310] recognized this difference and highlight it in
> the Introduction section with this statement:
> >
> > "The proposals here might be adapted or extended in future to be used
> for recursive clients and authoritative servers, but this application was
> out of scope for the DNS PRIVate Exchange (dprive)
> >     > Possibly, but it may also be worth discussing how to avoid getting
> into resource exhaustion situations in the first place. Do you have any
> thoughts on Karl's "need for a profile of encryption
> > standards" comment?
> >
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Christian Huitema <[email-masked]>
Date: Sun, 2 Dec 2018 22:49:54 -0800

On 12/1/2018 4:41 AM, Hugo Connery wrote:
...
> the community within those network(s) is "the internet does

The non-ISP resolvers like 8.8.8.8 or 1.1.1.1 are actually much more
than "a tiny fraction of the Internet". When we measure that, we find
that they server at least a quarter and maybe a third of Internet users,
worldwide.

...

> within network(s).  

You wish. We actually track that as part of ICANN's "Identifier
Technology health Indicators" (ITHI). The results are available at
https://ithi.research.icann.org/graph-m5.html. (The data are collected
by APNIC.) We can determine that 30% of resolvers re-fetch according to
TTL, 16% don't, and 54% do their own thing that we cannot really
categorize. Plus, 11% of resolvers "auto-refresh" their caches, i.e. do
their own queries without waiting for user traffic; these 11% of
resolvers serve 63% of Internet users.

As for the number of resolvers, there are a few big ones, but there is
also a very long tail. We measure that the top 10,000 resolvers serve
92% of users. We see about 20,000 more after them serving few users, and
then there is of course another portion of the long tail that we don't see.

Looking at root servers produces similar data, and then some. Root
servers don't just see "regular" traffic, they also attract lots of
random sources.

> This is not a perfect protection because

Maybe. The numbers above give an idea of the size of the field. Big
servers can probably maintain a list of the top 10,000 plus the next
20,000 or so. For small servers, that will be harder, because they will
only see a fraction of the resolvers on a given day, and that could very
well change day to day. It would be nice if whatever we do does not come
as yet another reason to concentrate all the services on a few big
platforms...

-- Christian Huitema

---

From: Brian Haberman <[email-masked]>
Date: Mon, 3 Dec 2018 10:04:56 -0500

Hi Karl,
     I can slot this in right after the Alex/Benno slot.

Regards,
Brian

On 11/29/18 1:03 PM, Henderson, Karl wrote:
> As a representative of a large root and tld operator, I’d like to request ~10 minutes (in case my comments spark discussion) on the dprive interim agenda in order to make some observations and recommendations regarding privacy between the recursive and authoritative name servers.
> 
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 5 Dec 2018 09:25:40 -0500 (EST)

On Fri, 30 Nov 2018, Paul Hoffman wrote:

> (D)TLS is not the only option. Using message security instead of connection security would eliminate the need for keeping TCP and crypto state on the server, and could maybe reduce the amount of CPU usage as well.

Is there a draft that describes this message security? Or is that part
of the work to be started?

It seems that before dprive publishes a (D)TLS profile, that this path
should be considered first?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Dec 2018 15:04:28 +0000

> of the work to be started?

The latter.

> should be considered first?

Maybe, or maybe they can be done in parallel. There are already plenty of message security standards to start from (COSE, CMS, OpenPGP), and "encrypt a simple DNS message body" is trivial. What is less trivial is weighing the costs and benefits to resolvers and authoritative servers, which is the work that is going to start happening soon.

--Paul Hoffman

---

From: Brian Haberman <[email-masked]>
Date: Wed, 5 Dec 2018 10:35:20 -0500

Hi Paul,

> Maybe, or maybe they can be done in parallel. There are already plenty of message security standards to start from (COSE, CMS, OpenPGP), and "encrypt a simple DNS message body" is trivial. What is…

I think it would be quite useful if someone were to explore the use of
message layer security in the context of DNS. That could be one of the
ones you listed above or it could be the work in MLS. Or even Double
Ratchet.

If any of these helped reduce the potential state management problem for
DNS authoritative servers, that would be a major benefit IMO.

Regards,
Brian

---

From: Tony Finch <[email-masked]>
Date: Wed, 5 Dec 2018 15:37:04 +0000

Paul Hoffman <[email-masked]> wrote:
>
> There are already plenty of message security standards to start from
> (COSE, CMS, OpenPGP)

SIG(0) :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
disperse power, foster diversity, and nurture creativity

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Dec 2018 15:49:53 +0000

On Dec 5, 2018, at 7:35 AM, Brian Haberman <[email-masked]> wrote:
> message layer security in the context of DNS.

That's my intention.

> That could be one of the
> ones you listed above or it could be the work in MLS.

What does MLS bring to the table that is not in the already-standardized formats?

> Or even Double

I thought that double ratchet was for online protocols, not message protocols. 

> DNS authoritative servers, that would be a major benefit IMO.

It would be good to hear the needs of both sides first. HTTP over TLS has proven that it is quite possible to use an online security protocol even for lots of short messages. Amortizing the big CPU calculations may counterbalance the cost of the state management, or it might not.

--Paul Hoffman

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 5 Dec 2018 22:22:49 +0530

On Wed, Dec 05, 2018 at 03:49:53PM +0000, Paul Hoffman wrote:
> It would be good to hear the needs of both sides first. HTTP over TLS
> has proven that it is quite possible to use an online security
> protocol even for lots of short messages. Amortizing the big CPU
> calculations may counterbalance the cost of the state management, or
> it might not.

Nod, HTTPS has demonstrated that TLS can be scalable (even more so in
recent years) and DNS is not different in this aspect. This is one
aspect for protocol selection. I also worry about roundtrips in
recursive resolution. If a message security scheme can somehow work as a
stateless request-response protocol where prior state establishment is
not necessary, it can reduce time to respond to queries comparable to
traditional DNS. This was not a problem for stub->resolver transport
where processing a client request is limited to talking to one peer, and
RTT to a resolver is usually low. resolver->auth is different where the
transport can be used many times for a single client query.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 5 Dec 2018 22:36:39 +0530

> transport can be used many times for a single client query.

Unexpected latency here can not only badly impact user experience, but
cause timeouts. FWIW, a stub resolver such as glibc would typically
timeout a query in 5 seconds and make a second attempt (possibly to a
different nameserver) if the first one fails. This may or may not
totally take 5 seconds in all. dig will timeout each fetch at 5 seconds
by default, and try up to 3 times in all before it gives up. The need to
answer within such time is why the serve-stale draft has a "client
response timer".

These circumstances can also occur with regular DNS with a lot of
indirection (several NS lookups in servicing a single client query) and
high RTT to nameservers. E.g. BIND can wait from 10 upto 30 seconds for
a resolution to timeout based on configuration, but its client usually
won't wait that long, but named can at least insert the resolution
result into cache for future queries. Stub timeout behavior is something
to consider when switching transports.

		Mukund

---

From: Brian Haberman <[email-masked]>
Date: Wed, 5 Dec 2018 12:14:05 -0500

> What does MLS bring to the table that is not in the already-standardized formats?

While MLS is still in its infancy, it is designed for many-to-many
communications. That may be beneficial when we are talking about
authoritative servers using anycast.

Brian

---

From: Paul Wouters <[email-masked]>
Date: Wed, 5 Dec 2018 12:23:09 -0500 (EST)

> authoritative servers using anycast.

MLS is about authenticated (group) chat. In this case, the is a big
need for the querier to remain anonymous and not to present any
identity. MLS would be an extremely poor fit and bring in a number
of other concerns, such as depencies on registration services,
authentication services, etc. etc.

It's the wrong hammer for DNs privacy

Paul

---

From: Brian Haberman <[email-masked]>
Date: Wed, 5 Dec 2018 12:29:29 -0500

Hi Paul,

> authentication services, etc. etc.

That's a good point that I hadn't considered.

> It's the wrong hammer for DNs privacy

Thanks for the quick response on MLS.

Regards,
Brian

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 10 Dec 2018 09:55:20 -0500

> DNS authoritative servers, that would be a major benefit IMO.

It's not clear to me that MLS has significantly less state to manage
than TLS 1.3.  Indeed, it might require *more* state management.  Can
you point to information that suggests there is less of a burden of
state for MLS implementations? Is statefulness the main concern you're
trying to address?

             --dkg

---

From: Brian Haberman <[email-masked]>
Date: Mon, 10 Dec 2018 10:20:44 -0500

Hi dkg,

> state for MLS implementations? Is statefulness the main concern you're

State management has been a common theme for some people's concerns. At
this time, I don't think we have a solid view on whether state is the
highest priority, but it certainly gets a lot of attention.

As for MLS, I think the quick exchange with Paul W. has led to MLS not
looking like a good fit. I mentioned it for completeness when message
layer security was raised.

Regards,
Brian