Subject: [dns-privacy] On behalf of Apr 1st, here is a DNSE solution.

From: Wes Hardaker <[email-masked]>
Date: Tue, 01 Apr 2014 14:43:10 -0700

The problem with other solutions is that you (a DNS user) must trust
someone not to have been hacked or to sell you out.

This solution is a super-hack, but shows the type of architecture needed
to ensure that no entity but you knows both:

  - who made the request
  - what the request (and response) contains

Anyone that knows both is a potential point of compromise.

  http://datatracker.ietf.org/doc/draft-hardaker-dnse-split-key-dns/ 

Warning: the security in here is not.
-- 
Wes Hardaker
Parsons

---

From: Joe Abley <[email-masked]>
Date: Tue, 1 Apr 2014 17:46:14 -0400

> Anyone that knows both is a potential point of compromise.

That was the basis of our onion-smelling proposal, too:

  http://tools.ietf.org/html/draft-jabley-dnsop-dns-onion-00

   This document describes an approach which separates the data in DNS
   queries and responses from the identity of the DNS resolver used by
   DNS clients.

[...]

   This is an incomplete proposal.  It has been distributed in its
   current form for the purposes of discussion, such that the high-level
   approach can be considered amongst other options in the general
   consideration of DNS privacy.

   The authors have called out particular gaps in this document.  The
   authors are confident that there are many other gaps that have not
   been mentioned.  The absence of a description of a gap in this
   document does not imply there is no gap.  Contents may have settled
   in transit.  Your statutory rights are not affected.

   The origins of this document lie in a beer-soaked afternoon
   conversation in the lobby bar of the Hilton Metropole, London, UK.
   Should this document play any future part in preserving human life or
   dignity, the authors recommend the installation of a small but
   elegant brass plaque, the text embossed upon which should naturally
   be encrypted.

Joe

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 1 Apr 2014 23:47:35 +0200

> The problem with other solutions is that you (a DNS user) must trust
someone
> not to have been hacked or to sell you out.
> 
to
> ensure that no entity but you knows both:

Not all solutions....  This is not actually a problem with CGA-TSIG. :-)  

Hosnieh

---

From: Phil Regnauld <[email-masked]>
Date: Wed, 2 Apr 2014 00:43:20 +0200

> Warning: the security in here is not.

"In order to protect against this threat, the endEntity must transmit
 the request to the recursive resolver in such a way that the
 recursive resolver in such a way that the recursive resolver must not
 be aware of which end entity sent the request in the first place."

Man, reading that sentence, I had the feeling that sentence that I had
read it twice.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 01 Apr 2014 17:56:26 -0700

> Man, reading that sentence, I had the feeling that sentence that I had

I wrote it twice, so it worked.

Somewhere in the abstract I should have put "what follows is random,
unproofread, typing that may or may not make sense".
-- 
Wes Hardaker
Parsons

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 2 Apr 2014 09:37:01 +0200

On Tue, Apr 01, 2014 at 02:43:10PM -0700,
 Wes Hardaker <[email-masked]> wrote 

>   http://datatracker.ietf.org/doc/draft-hardaker-dnse-split-key-dns/ 

You mention the risk coming from the resolver. That's why, IMHO, we
should recommend people to run a local resolver, as much as possible
(I'm aware it may not always be possible, for instance for constrained
devices). See section 2.2.1 of draft-bortzmeyer-dnsop-privacy-sol-00

This leaves us with the authoritative name servers learning the
request. Caching protects a bit. For the rest, that's where qname
minimisation or minimization comes into play. The authoritative name
servers will still learn things but not as many things. See
draft-bortzmeyer-dns-qname-minimisation

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Apr 2014 15:04:22 +0100

> should recommend people to run a local resolver, as much as possible

If (big if) you trust the resolver then you have the advantage of hiding
your iteratve queries in the aggregate behaviour of the resolver's other
users, and if the connection to your resolver is encrypted it is
relatively difficult for a snooper to work out what you are asking for. If
you run the resolver locally then it becomes really easy to do traffic
analysis on your DNS, because even if it is encrypted the attacker has
your authoritative server addresses as well as the packet sizes to work
with.

So I don't think the trade-off is simple enough to make a blanket
recommendation.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet: South or southwest 3 or 4, occasionally 5 later. Slight or
moderate. Occasional rain with fog patches, becoming fair. Moderate,
occasionally very poor, becoming good.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 3 Apr 2014 23:17:34 +0800

On Wed, Apr 2, 2014 at 3:37 PM, Stephane Bortzmeyer <[email-masked]> wrote:
> request.

... 'm still confused by this bit.

If I'm running a local resolver and my machine makes a connection to
ns1.example.com, presumably it's because I'm trying to lookup a record
in the example.com zone (assuming ns1.example.com is only
authoritative for a small number of zones). Sure, I could be looking
up www.example.com or mail.example.com or foo.example.com but it's
still clear I'm going to example.com....

As an example of this, if my resolver makes a connection to
199.193.245.198 it's quite clear I'm going to
http://www.smartrecovery.org/ (I wanted to use Alcoholics Anonymous,
but they use ns.rackspace.com, just like ~2,500 other folk).
Perhaps we don't care, because folk who run their own DNS likely run
"dedicated" web servers, and so it's clear for someone on the wire
where they are going anyway?!

W

> Caching protects a bit. For the rest, that's where qname
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Apr 2014 14:10:00 -0700

> devices). See section 2.2.1 of draft-bortzmeyer-dnsop-privacy-sol-00

But that doesn't really mitigate everything.  Anyone sniffing the wire
either near you or even near the resolver in question can see who is
making the traffic and where it's going.  To get secured deployment
using a local resolver scheme, you still have to have the local resolver
doing DTLS (or equivalent) from it to everywhere, and the destination
NS still gives a lot away even if you could encrypt everything
everywhere "soon".

I do agree that everyone should use a local resolver.  Or, even better,
smarter in-application validating APIs with local caches.

Anyway, the hack in my Apr 1. document gets around these problems by
only needing a few of the distant anonymizing resolvers in place.  

(FYI, in the document I listed the suggested name as
EEEE.K1.example.org, but it really should be reversed to provide easier
state tracking in both places:  K1.EEEE.example.org).  
-- 
Wes Hardaker
Parsons

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 4 Apr 2014 10:10:44 +0200

On Thu, Apr 03, 2014 at 03:04:22PM +0100,
 Tony Finch <[email-masked]> wrote 
 a message of 23 lines which said:

> If (big if) you trust the resolver then you have the advantage of
> hiding your iteratve queries in the aggregate behaviour of the
> resolver's other users,

You can have your cake and eat it: run your own resolver and forward
the uncached queries to a shared resolver (your IAP's or Google Public
DNS, as you wish). This is automatically done by the excellent tool
dnssec-trigger, which probes the shared resolver before using it in
forwarding.

Because of the local resolver, you will send less info to the shared
resolver. Because of the shared resolver, you will send less info to
the authoritative name servers.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 4 Apr 2014 10:50:04 +0200

On Thu, Apr 03, 2014 at 02:10:00PM -0700,
 Wes Hardaker <[email-masked]> wrote 
 a message of 27 lines which said:

> Anyone sniffing the wire either near you or even near the resolver
> in question can see who is making the traffic and where it's going.
> To get secured deployment using a local resolver scheme, you still
> have to have the local resolver doing DTLS

Yes, as I have said in physical meetings or in my drafts, there is not
one solution that will solve everything. We need data minimisation (or
minimization) _and_ encryption.