Subject: [dns-privacy] Deployment issues

From: "Christian Huitema" <[email-masked]>
Date: Thu, 2 Jun 2016 10:56:29 -0700

I have been pondering DNS Privacy issues for some times, and I read with
interest a recent blog by Geoff Huston and Joao Luis Silva Damas
(http://www.circleid.com/posts/20160526_the_path_to_dns_privacy/).
Basically, we have two trends, somewhat conflicting. On one side, DPRIVE is
standardizing an encrypted connection to a trusted recursive resolver; on
the other side, efforts like GetDNS would generalize the use of recursive
resolvers on the client itself. There are pros and cons on both sides.

The privacy benefits of DPRIVE depend on the trusted resolver handling lots
of traffic. If the trusted resolver handled only one customer at a time, it
would be easy to correlate the encrypted messages coming to the server and
the clear text queries sent to the authoritative resolvers, and there would
be little privacy gains. If the resolver handles millions of queries,
correlation becomes much harder, but something else happens. The big
resolver becomes a very tempting target for attacks, from data mining to
criminal hacks, legal warrants, censorship mandates, or secret national
security letters. 

The distributed approach is somewhat more robust against attacks, especially
if the distributed resolver implements QName Minimization. But there is
little privacy if the queries are sent in clear text. In fact, clear text
queries can also be attacked with a combination of deep packet inspection
and automated spoofing - some big national firewalls are already doing just
that, and the infamous "quantum Insert" service was doing something similar.
DNS SEC will allow resolvers to detect the attack, downgrading them from
MITM to denial of service, but that's not exactly perfect robustness. 

So, what shall we do? I suppose recursive resolvers could use DNS over TLS
to get data from authoritative resolvers. Or DNS over DTLS. Or a variation
of DNS over HTTPS. But are we standardizing that? Is this part of DPRIVE's
charter?

-- Christian Huitema

---

From: Robert Edmonds <[email-masked]>
Date: Thu, 2 Jun 2016 14:11:26 -0400

Christian Huitema wrote:
> Is this part of DPRIVE's charter?

    "...but it may also later consider mechanisms that provide
    confidentiality between Iterative Resolvers and Authoritative
    Servers, or provide end-to-end confidentiality of DNS transactions."

-- 
Robert Edmonds

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 2 Jun 2016 18:14:02 +0000

Hi,

I  tried to point this out at the beginning;

  encrypting connections to local caching resolvers 
  without encrypting the auth resolver connection 
  gives the same security as Tor Browser.

But, something is better than nothing.  Better for the world 
having the "I live in an anonymity set" security than none.  

If that set is small, you are hosed.

/Hugo

Or, we need to encrypt the caching to auth connection.
There is no way out of this.

---

From: Dan York <[email-masked]>
Date: Thu, 2 Jun 2016 18:39:12 +0000

> On Jun 2, 2016, at 2:11 PM, Robert Edmonds <[email-masked]> wrote:
> 
> Christian Huitema wrote:

Yes, there was a great bit of discussion about this back when DPRIVE formed.  My recollection is that we decided to focus on the stub resolver to recursive resolver *first* because the view was that this would protect the largest surface area against attacks. The view was that there were many, many more stub resolvers and fewer recursive resolvers.

We also didn't want to "boil the ocean" and wanted to have focused, achievable milestones.

To me what Christian is pointing out is that if there is change happening within the Internet's infrastructure to increasingly move recursive resolvers into the user clients... well... then perhaps the "later" in the charter has arrived and it's time to start looking at that next step.

Dan

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 2 Jun 2016 22:01:24 +0000

Hi,

I hope the WG will start looking at that "next step".

There are resource issues with running TLS to auth servers.

But, that is easily solved: the people who want to do this 
bear the burden, and those that dont get publically shunned
(and possibly dont care).

Hugo Connery
________________________________________
From: dns-privacy [[email-masked]] on behalf of Dan York [[email-masked]]
Sent: Thursday, 2 June 2016 20:39
To: Robert Edmonds
Cc: [email-masked]; Christian Huitema
Subject: Re: [dns-privacy] Deployment issues

Dan

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

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 2 Jun 2016 22:08:58 +0000

so, lets get 8.8.8.8 running TLS DNS as a push.

Hang on, they are a sruveillence/advertising business!  No problem,
it is just they who can surveill.

Hmmm,
________________________________________
From: dns-privacy [[email-masked]] on behalf of Hugo Maxwell Connery [[email-masked]]
Sent: Friday, 3 June 2016 00:01
To: Dan York; Robert Edmonds
Cc: [email-masked]; Christian Huitema
Subject: Re: [dns-privacy] Deployment issues

Hi,

Hugo Connery

Dan

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Jun 2016 18:50:03 -0400 (EDT)

> it is just they who can surveill.

It still makes sense to reduce the number of people that can read your
DNS requests, just like it makes sense to use https to google.com.

Paul

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 3 Jun 2016 08:31:27 -0400

> On Jun 2, 2016, at 6:50 PM, Paul Wouters <[email-masked]> wrote:
> 

Stéphane Bortzmeyer’s QNAME minimization (RFC 7816) is a great example of work being done on resolver privacy.

Tom

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 3 Jun 2016 10:26:50 -0700

On Thursday, June 2, 2016 3:50 PM, Paul Wouters wrote:
> > Hang on, they are a sruveillence/advertising business!  No problem, it
> > is just they who can surveill.
> 
> It still makes sense to reduce the number of people that can read your DNS
> requests, just like it makes sense to use https to google.com.

Yes. And we have an interesting issue with the size of the service. In
theory, anybody could set up a recursive resolver somewhere on the Internet,
and provide privacy services using RFC7858. For example, I could set
something like "private-resolver.huitema.net" on a server that I control.
The traffic to that resolver would be duly encrypted. I may even implement
counter measures in the server to make it hard to guess the actual queries
relayed by the resolver. And then, I could program my laptop to always use
that resolver. But then, in the name of privacy, I would have just built the
opposite, a tracking beacon. There is exactly one user for
"private-resolver.huitema.net." Tracking traffic there provides a pretty
good indication on the movements of my laptop.

Even if the service had a few hundred or a few thousands customers instead
of just one, we would still have a traffic effect. Tracking that access
narrows the search to these few thousands customers. That's a pretty good
identifier. So here we are, with one leg of the dilemma: use small servers
for RFC 7858 allows tracking of the users.

Now, if we have big servers, we do not have the same issue. If 15% of the
Internet uses 8.8.8.8, tracking that narrows the search space to something
like 150 million users. Not a very big deal. But then, we have the other leg
of the dilemma. Even if the provider of 8.8.8.8 is trying to not be evil,
they are big, and thus they are a fat big target. They have to abide by
every censorship and tracking requirements in the country in which they do
business. They can receive secret letters from the security services
compelling them to do some evil stuff. They can be the target of hacks by
state sponsored "cyber warriors." They could even at some point get
pressured to show revenues for the service, and start engaging in data
mining.

So, yes, we do have a problem. Either small and cuddly and easy to track. Or
big and robust and a target for hacks and threats. That's better than
nothing in the short term, but we should not stop there.

-- Christian Huitema

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Jun 2016 13:33:32 -0400 (EDT)

> for RFC 7858 allows tracking of the users.

You would chain various DNS caches together, so a query to one populates
them all. You'd also cause a bunch of them to query it and use
pre-fetching to ensure all caches will have these answers. Still, there
are issues with geolocation, etc.

> nothing in the short term, but we should not stop there.

Yes. Therefor, we should encrypt everything always all of the time :)

Paul

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Fri, 3 Jun 2016 17:51:21 +0000

Well said, Christian.

I would like to err on the side of "many smaller", based on the
comments by Bruce Schneier; we were safer in the days when
there were 10 000 email providers.

I feel that this, combined with DNS over TLS and QNAME minimisation,
and the padding, is a significant step forward, and I applaud the community and
WG for their efforts.

Now we need the customers to convince their ISP that these matters
are important, and then we get the 10 000 (or whatever) privacy
secured DNS servers.  I will be starting with my infrastructure 
and then pressuring my ISP.

We do still need the recursive to auth encryption ...

/Hugo
________________________________________
From: Christian Huitema [[email-masked]]
Sent: Friday, 3 June 2016 19:26
To: 'Paul Wouters'; Hugo Maxwell Connery
Cc: [email-masked]
Subject: RE: [dns-privacy] Deployment issues

-- Christian Huitema

---

From: John Heidemann <[email-masked]>
Date: Mon, 06 Jun 2016 09:35:42 -0700

On Fri, 03 Jun 2016 10:26:50 -0700, "Christian Huitema" wrote: 
>Yes. And we have an interesting issue with the size of the service.
>
>...
>

Those extremes pose the challenges you describe.

Those same challenges arise with privacy of other user behavior, such as
e-mail origination or destination.

An important conclusion is your "we should not stop there".

DNS-over-TLS is a PART of a solution, it is not a "magic privacy bit"
that, when flipped, creates perfect DNS privacy.  I think RFC-7858 is an
important step, there will be other steps for people who wish to be
robust to greater threats.

The world of private e-mail has a number of well known techniques.
DPRIVE is already considering considering padding.  Other well approaches are
striping queries across multiple servers, and adding "chaff" queries.
(I'm not sure that those approaches require standardization---they could
be done by any interested client.)

Over time, individuals will pick the level of protection they think is
appropriate.

But the existence of some remaining attacks should not discourage
progress.  For example, I think a recently published attack threatened
to break RSA keys using acoustic emissions from laptop CPUs.
Personally, that threat is not my top current worry :-)

   -John Heidemann

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jun 2016 12:29:14 +0200

On Fri, Jun 03, 2016 at 01:33:32PM -0400,
 Paul Wouters <[email-masked]> wrote 
 a message of 40 lines which said:

> You would chain various DNS caches together, so a query to one
> populates them all.

Cool idea. We could take inspiration from RFC 2186/2187.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jun 2016 13:39:59 +0200

On Mon, Jun 06, 2016 at 09:35:42AM -0700,
 John Heidemann <[email-masked]> wrote 
 a message of 53 lines which said:

> Other well approaches are striping queries across multiple servers,
> and adding "chaff" queries.  (I'm not sure that those approaches
> require standardization---they could be done by any interested
> client.)

I would call it "gratuitous queries" instead. Chaffing is for me a
specific technique
<http://people.csail.mit.edu/rivest/chaffing-980701.txt>. Gratuitous
queries are close to padding, and, like padding, can be hard to do
properly (without allowing retrieval of the interesting
information). A guidance RFC would still be useful even if there is no
protocol change.