Subject: [dns-privacy] Confidentiality from Iterative to Authoritative resolvers.

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 23 Oct 2014 11:36:06 +0000

Hi,

Working on an effective solution for confidentiality
of stub to iterative resolvers seems an essential part
of the WG's mandate.  Input from P Vixie and others
seems to have this moving.

Thanks to Ted Hardie and Mark Andrews for expanding on
the issue of, and beginning a discussion of a potential
solution to, respectively, the iterative to authoritative
resolver DNS information leakage.

DNS information is clearly public information.  But that
does not mean that one needs to publish *who* is accessing
that public data.

As an ananlogy: the collection of books in a public library
may be considered 'public' information.  Nonetheless,
librarians expend effort to restrict access to the
information of who is borrowing the items.  i.e the
information itself is public, but the information of who
is accessing it does not need to be.

I encourage the WG to agree on a manner for confidentiality
between iterative and authoritative resolvers.  I suggest
that this would be an optional service (MAY not MUST),
at least to begin with.  The addition of encryption
adds a considerable weight; UDP -> TCP and handshakes
and ciphters.  Thus, it may take some time before many
authoritative resolvers are provisioned to provide
confidential query services.

Should the WG not wish to create the possibility of
confidentiality the resolvers, I hope that it at
least characterises the type and scope of what information
is being leaked.  Perhaps that should be done anyway.

I am quite happy to begin work on just that, should that
be desired.

Regards,  Hugo Connery
--
Technical University of Denmark

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Oct 2014 13:08:19 +0100

I think the answer to this question may be a simple "no, don't"
but it if were not, it might be something that'd improve privacy
for both stub<->recursive and recursive<->authoritative without
changes to the DNS, but probably requiring some new protocol to
run alongside. Anyway...

> does not mean that one needs to publish *who* is accessing

Another way in which one could conceivably do that is by issuing
bogus requests, (i.e. padding) which attempts to mask not who is
asking but which answers are of interest.

That wouldn't have to be a case of sending queries for randomly
generated names, but could be based on some form of gossip between
a bunch of e.g. recursives or something. So the bogus request that
one sends out might actually be for a domain that was a real
request from another gossipy recursive a while ago.

I suspect that there's not much to be gained by doing that in
the end, and it'd clearly have costs, (though with gossiping
one might limit those by getting a lot of cache hits) but I
wonder if anyone has looked at this kind of thing in detail
already?

A v. quick search didn't turn up that much, though [1] seems
to be proposing something along these lines.

Cheers,
S.

[1] Federrath, Hannes, et al. "Privacy-preserving DNS: analysis of
broadcast, range queries and mix-based protection methods." Computer
Security–ESORICS 2011. Springer Berlin Heidelberg, 2011. 665-683.
http://202.154.59.182/mfile/files/Information%20System/Computer%20Security%20-%2016th%20ESORICS%202011/Chapter%2036%20Privacy-Preserving%20DNS%3B%20Analysis%20of%20Broadcast,%20Range%20Queries%20and%20Mix-Based%20Protection%20Methods.pdf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Oct 2014 11:35:30 -0400

> asking but which answers are of interest.

That isn't what I would call padding. Increasing the length of genuine
request packets to resist traffic analysis has a lot less cost than
generating spurious traffic. Yes, I might do that sort of thing in an
application designed for people who are surveillance targets but the
cost/benefit really does not justify generating traffic noise as a general
rule.

In Private-DNS I support padding to obfuscate traffic analysis based on the
length of a request because this can actually leak rather too much
information. So for example, consider the case in which someone is going to
www.cnn.com, or www.bbc.com or the like. Short domain names are valuable
and so most are used by sites that generate a lot of traffic. Folk who are
visiting such sites are probably not doing anything unusual. The longer the
domain name, the more likely someone is doing something unusual.

Padding request packets to a multiple of 64 bytes greatly reduces the value
of collecting this data and imposes negligible additional cost.

> request from another gossipy recursive a while ago.

I don't like the idea of makework traffic but one potential benefit of
DNSSEC is that such traffic could well become rather useful.

> wonder if anyone has looked at this kind of thing in detail

Back in the early days of the Web there was a project called Harvest that
made use of such approaches. That project led to the technology behind
Tucows. It also spawned the squid reverse proxy. This was HTTP layer rather
than DNS, but the architecture worked fine.

This isn't something I would necessarily endorse for general use. But if I
have a resolver that gets a request packet from Iran and a cache miss, I
might well want to disguise the contact to an authoritative by routing
through a sister resolver. But preventing that being spotted would probably
require me to be doing enough chatter with the sister for other purposes to
hide the traffic.

This is one of the reasons I designed Private-DNS the way I did which is as
a general purpose layer supporting fast Web Service transactions.