Subject: [dns-privacy] A pool is not an onion

From: "Christian Huitema" <[email-masked]>
Date: Sat, 25 Oct 2014 17:54:22 -0700

> Decentralising caches could actually be worse for dns privacy, as your
query no longer stops in the big ISP pool to gain some anonymity, but
instead links straight to you with specific TTLs on your personal cache
expiry/re-fetch timers.

I have heard this "pooling" argument quite a few time. The idea is that if I
send my requests through a big enough recursive resolver, I gain anonymity
because the reply may be cached, or the request may come from the pool
instead of coming from me. The problem with the argument is that it expects
privacy to result as a side effect from something else, in that case
caching. But this is a week argument. For example, if the target resource is
rarely accessed, the output to fetch "kinky.example.org" can be easily
correlated with the arrival of an encrypted request to the resolver, and
thus to the original IP address. This is even more true if the target DNS
name is set with a short TTL.

Compare that to onion routers like Tor that are specifically engineered for
privacy, and which do not rely on side effects. If I wanted to hide my
footprints, I would have much more trust in something engineered for privacy
than on an hypothetical side effect. So, if really care about hiding
requests, then maybe we should consider an onion network of DNS resolvers,
of course connected by ecrypted links. Or maybe use DNS over HTTPS over Tor.

-- Christian Huitema

---

From: Warren Kumari <[email-masked]>
Date: Sat, 25 Oct 2014 21:48:05 -0400

On Sat, Oct 25, 2014 at 8:54 PM, Christian Huitema <[email-masked]> wrote:
> instead of coming from me.
> The problem with the argument is that it expects
> thus to the original IP address.

A fair bit of this has already been discussed (including an onion
style solution) - see
http://www.ietf.org/mail-archive/web/dns-privacy/current/msg00054.html
as an example.

In order to develop a deployable solution we will have to make some
compromises -- if the recursive server is busy, is not part of a pool,
and "kinky.example.org"  is not in the cache, you still get some
protection - a busy recursive has some set of outstanding queries, and
is handling a number of clients - correlating your incoming packet
with a request for "kinky.example.org"  is believed to be somewhat
non-trivial.

> This is even more true if the target DNS
> of course connected by ecrypted links.

Yes, if you really care about hiding your queries then this is an option....
There is even a draft:
http://tools.ietf.org/html/draft-jabley-dnsop-dns-onion-00

> Or maybe use DNS over HTTPS over Tor.

...as is this. Or DNS over HTTPS over Tor over a VPN and a proxy.
It all depends on what *your* threat model is, and what tradeoffs you
are willing to make.

One of the things that we are focusing on is a deployable solution,
preferably one that resolver operators can roll out on their own. If
the solution is overly complex, takes too long to develop, or add
significant latency then it is not as likely to be deployed, or will
take a really long time to be deployed - during which time we are
leaving lots of users with their queries in the clear.

We need to be careful to avoid falling into the perfect being the
enemy of the good trap... I'd rather see a deployed solution that
protects 99.99% of queries that gets deployed than a 100% solution
that never gets implemented.

“Give them the third best to go on with; the second best comes too
late, the best never comes.” - Sir Robert Alexander Watson-Watt's
"cult of the imperfect". This refers to the radar solution that he
helped develop for England, and the fact that it could have gotten
higher resolution / performance with a higher frequency... but would
have taken much longer to get developed...

W

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

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 25 Oct 2014 22:04:19 -0400

I think that we have to go back to the original goal, to reduce leakage of
information so that we only disclose where there is a need to know.

The authoritative does not need to know who is making the request.

The TLD does not need to know the complete query.

At some point a recursive somewhere does need to know that a query is being
made. That puts client/resolver leakage in a different category to
client/authoritative.

Yes protecting that data might warrant investigation. Yes, I and others can
suggest schemes that would provide that protection. No, this is not
costless. No this is not a low hanging fruit. No this should not be our
focus in DPRIV right now.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 25 Oct 2014 19:35:11 -0700

> made. That puts client/resolver leakage in a different category to

Before DPRIV: anyone who owns the DNS box at an ISP can see all
dns-queries go through, and know who made them.

After: exactly the same.

Why? Because we were lazy, and solved the easy problems instead of the
worthwhile problems.

> focus in DPRIV right now.

So we shouldn't solve the problem we want to solve, because solving
the problem we want to solve is hard, so we should solve the problem
we can solve and fool ourselves into saying we wanted to solve it, and
hope no one else notices? Put me down as thinking that this is a
terrible idea.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 25 Oct 2014 22:40:35 -0400

> Why? Because we were lazy, and solved the easy problems instead of the

After the box does not have to be at the ISP.

After, you get to choose.

> hope no one else notices? Put me down as thinking that this is a

I am not at all convinced it is a problem that the world does want to solve.

By which I mean , wants to solve badly enough to fund the necessary
resources.

I have a protocol, sure. But I don't have a business model that is likely
to drive the deployment for general purpose adoption.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 26 Oct 2014 15:59:06 +0100

On Sat, Oct 25, 2014 at 07:35:11PM -0700,
 Watson Ladd <[email-masked]> wrote 

> dns-queries go through, and know who made them.

You seem to consider that DPRIVE = encryption of the stub-to-resolver
link and nothing else. But DPRIVE may work on other things that will
improve the situation such as recommending local (local = on the
user's machine or network) resolvers before, or instead, IAP's
resolvers.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 26 Oct 2014 08:09:19 -0700

> Why? Because we were lazy, and solved the easy problems instead of the

Or: because we don't have the same threat model that you are proposing, and we want something deployable. Nothing in the current proposals prevents you from proposing your still-academic PIR proposals for a longer-term solution that applies to people who agree with your threat model.

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Sun, 26 Oct 2014 08:17:59 -0700

On Oct 26, 2014 8:09 AM, "Paul Hoffman" <[email-masked]> wrote:
> Or: because we don't have the same threat model that you are proposing,
and we want something deployable. Nothing in the current proposals prevents
you from proposing your still-academic PIR proposals for a longer-term
solution that applies to people who agree with your threat model.

The choice of threat model is really a question about what attackers can
do. We know that untrusted network traffic can be read. (A truth DNS
working groups have never accepted) The only solutions that come close to
handling this are Qname minimization plus DNScurve.

Why don't the people who have proposals explain what they can deal with and
what they can't so we can judge?

Furthermore,  some PIR protocols amount to hashing together some records on
the server. While not perfect, they can be deployed and do make things
harder for attackers.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 26 Oct 2014 11:25:20 -0400

On Sun, Oct 26, 2014 at 10:59 AM, Stephane Bortzmeyer <[email-masked]>
wrote:

> One of the main reasons we get little done in security is that people tend
to derail discussions of the possible with demands for the perfect.

The other main reason is reductionism, demanding security solutions that
only fit in one box.

Traditionally the IETF demanded end-to-end security on a take it or leave
it basis. And so today 99.99% of email is not encrypted with PGP or S/MIME.
But something like 50% is secured using STARTTLS.

The reason I originally designed OmniBroker and PRIVATE-DNS was that I have
spent over ten years trying to get browser providers to implement DNSSEC so
we could do security policy and I know the constraints they raise. Their #1
concern is to minimize latency. In security concerns, preventing state
censorship is probably a higher concern than privacy. But only Mozilla is
likely to give a candid answer on that.

So we have a hierarchy of security concerns.

0) [Solved] Authenticity of authoritative data

1) Authenticity, Integrity and Confidentiality of DNS stub-resolver traffic

2) Confidentiality of DNS resolver-authoritative traffic

3) Disclosure by the resolver

We can address (1) very simply and cheaply and do so in a fashion that is
compatible with (3). What we can't do is to provide (3) without severe
impact on latency.

And if you don't solve the latency problem then you end up with the Harvard
TOR-DOX issue. Use of TOR is very thin so any use of TOR becomes suspect.
So when someone called in a bomb threat to avoid taking a final that day,
all the Harvard police needed to do was to look at the campus network logs,
find out who was using TOR when the threat was called in and call them both
in for interrogation.

We can address 1 and 2 with encryption. But solving 3 properly requires
steganography.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 26 Oct 2014 11:30:34 -0400

> solution that applies to people who agree with your threat model.
Well some of the proposals are better suited to dropping in an alternative
privacy protecting transport layer such as TOR than others.

This is a use case I have considered in depth for an interested party.
SXS-Connect allows a service to specify the transport. While UDP and TCP
are the defined values, someone could use TOR.