Subject: [dns-privacy] Pretty Bad Privacy: Pitfalls of DNS Encryption

From: Haya Shulman <[email-masked]>
Date: Tue, 23 Sep 2014 17:48:31 +0200

Dear members of the DNS privacy list, I recently did some work on the
privacy of DNS via encryption, where I investigated the challenges with
this approach. I would very much appreciate your comments, feedback and
thoughts. For your convenience, please find the abstract below; fyi the
paper is enclosed to this email.

​Many thanks in advance.​
Best regards.

 %%% TITLE %%%
Pretty Bad Privacy: Pitfalls of DNS Encryption

%%% ABSTRACT %%%
As awareness for privacy of Domain Name System (DNS) is
increasing, a number of mechanisms for encryption of DNS
packets were proposed. We study the prominent defences
focusing on the privacy guarantees, interoperability with the
DNS infrastructure, and the efficiency overhead. In particular:
1. We explore dependencies in DNS and show techniques
that utilise side channel leaks, due to transitive trust, al-
lowing to infer information about the target domain in an encrypted
DNS packet.
2. We examine common DNS servers con gurations and
show that the proposals are expected to encounter deployment obsta-
cles with (at least) 38% of 50,000-top Alexa domains and (at least) 12% of
the
top-level domains (TLDs), and will disrupt the DNS func-
tionality and availability for clients.
3. We show that due to non-interoperability with caches, the
proposals for end-to-end encryption may have a prohibitive
tra ffic overhead on the name servers.

Our work indicates that further study may be required to adjust the
proposals to
stand up to their security guarantees, and to make them suitable for the
common
servers' configurations in the DNS infrastructure.
Our study is based on collection and analysis of DNS traffic
 of 50,000-top Alexa domains and 568 TLDs.

%%% FIN %%%

-- 

Haya Shulman

Technische Universität Darmstadt

FB Informatik/EC-SPRIDE/CASED

Mornewegstr. 30, 64293 Darmstadt

Tel. +49 6151 16-75540

www.ec-spride.de/www.cased.de

sites.google.com/site/hayashulman

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 24 Sep 2014 15:57:16 +0200

On Tue, Sep 23, 2014 at 05:48:31PM +0200,
 Haya Shulman <[email-masked]> wrote 
 a message of 15002 lines which said:

> Dear members of the DNS privacy list, I recently did some work on
> the privacy of DNS via encryption, where I investigated the
> challenges with this approach. I would very much appreciate your
> comments, feedback and thoughts.

Thanks for the interesting paper, I learned many things. But I
disagree with the general conclusion (which can be summarized as
"encryption is almost useless") for the following reasons.

You say "it [DNS encryption] does not fully solve the privacy
problem". I wonder if there is even one security technique which fully
solves a problem. Security is mitigating the risks, not dreaming of
suppressing them. It is even more so for privacy: computers and
networks leak a lot of information and we try to limit the leak, not
to plug all the holes. The real question is not "does solution X fully
solve the problem?" because the answer is almost always no, but "does
solution X make life and work more difficult for the attacker, at a
reasonable cost for the defender?"

Also, I don't think that anyone suggested that encryption alone would
solve the DNS privacy problem. Following RFC 6973, we can say there
are two legs on which privacy walks: minimizing the data and
encrypting it. We need both. In the case of DNS, privacy will also
require things like QNAME minimization and local caching (caching
resolver in the users's premises or on its very own machine, may be
forwarding to bigger caches outside). So, saying that encryption alone
won't solve the problem will be no surprise for the readers of RFC
6973.

For your argument that DNS encryption would be a disruption for the
DNS, you say "the name servers of Alexa and TLDs have not adopted them
[encryption techniques]". Of course: none of these techniques is
standardized (and most are very recent and still untested). Speaking
for my employer, AFNIC would probably not deploy something that is not
at least on the standardization path (we may test it on less important
services). It is therefore unfair to criticize encryption on that
basis.

Speaking of deployment, you say things like "approximately 38% of
50K-top Alexa domains and 12% of TLDs are configured in the following
way: the IP address of an authoritative name server belongs to a
recursive DNS resolver". That's not a good argument: DNS encryption is
new and deployment will take time. "Weak links" like TLD with a RAN as
a name server will disappear with time. Bad practices today should not
be used as a reason to avoid improving the privacy. 

When you write "As we show, the existing proposals for encryption of
DNS packets between the resolvers and the name servers (settings (1)
and (3) in Figure 1) would not be effective in the RANS
configuration", I'm not impressed. Apart from a few big services like
OpenDNS, RANS are almost always unmanaged and abandoned configuration
errors. The fact that a solution does not work for them is not a big
problem.

For your other argument that leaks give sufficient information to the
eavesdroppers, you say "[leaks] which may enable an attacker to learn
the encrypted DNS content" and later "the attacker can accurately
guess which domain is accessed". You made a big step from "DNS
content" to "domain". DNS content (the full QNAME) is more than just
the domain (by which I assume you mean "registered domain", not
"domain name" in the usual DNS meaning). Without encryption, Eve,
sniffing example.com's name servers, can see that Alice requested
_bittorrent-tracker._tcp.example.com or bob-computer.example.com. With
encryption, if example.com is the only one present on the name
servers, Eve will just know that Alice requested
<something>.example.com. The difference is important and it is even
bigger for a TLD: if Eve manages to sniff AFNIC's name server's
traffic, encryption will limit her to learn that Alice is interested
in <something>.fr, a big win over the current situation.

For the interesting analysis in 3.2.2 about dependencies, an unstated
assumption is that the cache is cold. If it is not, the attacker will
have much less queries to use for his/her analysis. You mention the
possibility that the attacker clears the cache by various means but
you apparently did not test them (I doubt that BIND or Unbound will
move the NS records of .com out of the cache just because there have
been many requests for somethingNNNN.example.org). Anyway, clearing
the cache of the victim is an active attack and protecting against
passive attackers would be, in my opinion, already a good thing.

There is a technical error in the analysis iof zakon.kz in 4.1:
resolvers will send a request without the RD bit and, therefore,
Google Public DNS won't answer it:

% dig +norec @8.8.8.8 A zakon.kz

; <<>> DiG 9.9.5-4-Debian <<>> +norec @8.8.8.8 A zakon.kz
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40942
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;zakon.kz.		IN A

;; Query time: 6 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 24 15:52:26 CEST 2014
;; MSG SIZE  rcvd: 37

So, the configuration of this domain is most certainly a technical
error, not a trick to leverage the cache of Google Public DNS.

---

From: Antonio Prado <[email-masked]>
Date: Wed, 24 Sep 2014 16:27:58 +0200

> 
> On 23 Sep 2014, at 17:48, Haya Shulman <[email-masked]> wrote:
> 
> I would very much appreciate your comments, feedback and thoughts. For your convenience, please find the abstract below; fyi the paper is enclosed to this email.

hi haya,

just a quick comment:
did you evaluate what geoff huston recently wrote about dnssec cost?

http://www.potaroo.net/ispcol/2014-08/dnsseccost.html

thank you
--
antonio

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 24 Sep 2014 16:39:10 +0200

On Wed, Sep 24, 2014 at 04:27:58PM +0200,
 Antonio Prado <[email-masked]> wrote 

> did you evaluate what geoff huston recently wrote about dnssec cost?

What is the relationship with DNS privacy, since DNSSEC does not
provide privacy?

---

From: Antonio Prado <[email-masked]>
Date: Wed, 24 Sep 2014 18:09:18 +0200

> What is the relationship with DNS privacy, since DNSSEC does not

hi,

thanks for asking.

haya's document declares:
"we also study two additional aspects, instrumental to adoption of any
new mechanism in the Internet: interoperability with the existing
infrastructure and the efficiency overhead on the network and devices".

well, efficiency overhead is a common cost in both fields, dns privacy
and security, and it has been accurately illustrated in geoff's cited
article.
--
antonio

---

From: Haya Shulman <[email-masked]>
Date: Wed, 24 Sep 2014 19:05:50 +0200

Hi,

I am very grateful to everyone who spent the time to read the paper and
provide feedback.
All the comments that I received (both to personal email and here on the
mailing list) are excellent and thoughtful.

I would like to use this opportunity to thank Stephen Farrel for kindly
suggesting to share the writeup with this mailing list, and to Stephane
Bortzmeyer, who pointed out to me the importance of privacy for DNS last
year, when I was on a DNS security panel at CCC. Stephane's internet draft,
discussing the privacy concerns for DNS, provided a timely and convincing
motivation for the need to protect DNS - I believe this motivation will
significantly increase in the future, as the DNS infrastructure becomes
utilised for more systems and purposes.
This brings me to the next point - I was new to this topic (of privacy for
DNS) and was not aware of the massive amount of efforts of this community
to protect the privacy of DNS. Hence, I would like to thank all those that
referred me to the works that I have not covered in my study.
That draft was a ``first stab´´, and it focused on some of the schemes that
I was aware of, that attempt to protect DNS via encryption. I intend to
extend this work, in particular, I will also investigate the schemes that I
was not aware of, and will add appropriate citations. Many thanks for
sending those to me.

@Stephane: many thanks for your comments. Please see response below.

> "encryption is almost useless") for the following reasons.

[SH] I am concerned that the conclusion of the paper may have been
misinterpreted, I will try to clarify the text.

> ​

​[SH] I agree with you that encryption of DNS packets imposes further
difficulties on the attackers - the paper does not argue otherwise. What
imho the work shows, is that a determined attacker, that expends the
required amount of time and efforts, may still be able to learn sensitive
information, which encryption attempts to hide.
So, what I think the result means, is that someone who is really concerned
with hiding the queries, should be aware of the potential leaks.

> ​

​
[SH] Thank you for pointing this out, I will clarify this in the writeup.

​

> services). It is therefore unfair to criticize encryption on that
​
[SH] This is an excellent point. The fact that the defences are not yet
deployed was exactly why I investigated them - they are not yet
deployed/standardised, so not to late to check if something can be adjusted.
Changing standards is also more difficult, and less efficient. The history
shows that changing the standards, during the deployment phase when the
obstacles are discovered, causes confusion, extra efforts, addtional
deployment cycles, failures, and inevitably negative attitude towards the
proposed defence among the operational community, eventually resulting in
impeded adoption. So I hope that you will not take this work as an attempt
to criticise the efforts for encryption of DNS, but merely as a study of
the involved challenges, and the potential limits on the security
guarantees of this approach.
​

> be used as a reason to avoid improving the privacy.

​[SH] My impression is that there is an increasing tendency to outsource
services. But, maybe this practice (of running RANSes) will disappear. But
the work only focused on studying the existing infrastructure, so maybe one
of the outcomes is to get rid of RANSes. I ran a small survey and I found
that many of the network operators of domains that use RANSes are actually
not aware of this.

> errors. The fact that a solution does not work for them is not a big

​
[SH]
I found ISPs in the US and other (security aware) networks in the US that
support this configurations.
​ So, I do not think that it is reasonable to claim that this practice
applies only to security oblivious and mismanaged networks.​

​

> in <something>.fr, a big win over the current situation.

​
[SH] You are correct, the discovery proceeds in two steps: one discovering
the domain using the transitive trust dependencies and another also
utilises other side channels, such as the responses' size, to infer the
requested record within the domain. I will check if this should be clarifed
in the paper.

​

> passive attackers would be, in my opinion, already a good thing.

​[SH] This is correct, I used a cold cache, and I tested with Unbound and
Bind. Regarding com - this is less interesting leakage wise, since most
``interesting​´´ domains are under com. In such cases, the patterns
introduced by domains lower in the DNS hierarchy is more relevant.
BTW, I do think that this attack would require a significant effort from
the attacker, but it still does not elimitate the fact that there are leaks
that can be exploited by the attackers. In this work I did not consider the
question whether the attackers would bother to do this and which attackers
would bother to do this.

> Google Public DNS won't answer it:

​
[SH] This is correct, when the RD is no set it would respond from the
cache. I tested from various vantage points and all 8.8.8.8 hosts had that
entry cached.

​

> error, not a trick to leverage the cache of Google Public DNS.

Best regards.​

-- 

Haya Shulman

FB Informatik <https://www.informatik.tu-darmstadt.de/>/EC-SPRIDE
<http://www.ec-spride.de/>/CASED <http://www.cased.de/>/CROSSING
<https://www.crossing.tu-darmstadt.de/en/crossing/project-areas/s-solutions/s3-privacy-preserving-access-and-verifiable-utilization/>

Tel. +49 6151 16-75540

---

From: Haya Shulman <[email-masked]>
Date: Wed, 24 Sep 2014 19:42:01 +0200

BTW, pls see below a clearer response on the last point.

On Wed, Sep 24, 2014 at 7:05 PM, Haya Shulman <[email-masked]>
wrote:

> That draft was a ``first stab´´, and it focused on some of the schemes
> that I was aware of, that attempt to protect DNS via encryption. I intend
> to extend this work, in particular, I will also investigate the schemes
> that I was not aware of, and will add appropriate citations. Many thanks
> for sending those to me.
>
>
> [SH] You are correct, the discovery proceeds in two steps: one
> discovering the domain using the transitive trust dependencies and another
> also utilises other side channels, such as the responses' size, to infer
> the requested record within the domain. I will check if this should be
> clarifed in the paper.
>
> ​
>
>

​[SH] IMHO this may be an indication that this configuration is intentional
and ​not a configuration error.

-- 

Haya Shulman

Tel. +49 6151 16-75540

---

From: Haya Shulman <[email-masked]>
Date: Wed, 24 Sep 2014 19:45:47 +0200

Ciao Antonio, I was not aware of this article, thanks for referring me to
it. I will read and integrate a discussion.
Grazie 1000!!

On Wed, Sep 24, 2014 at 4:27 PM, Antonio Prado <[email-masked]> wrote:

> I would very much appreciate your comments, feedback and thoughts. For
> your convenience, please find the abstract below; fyi the paper is enclosed
> to this email.
>
>
> hi haya,
>
> just a quick comment:

-- 

Haya Shulman

Tel. +49 6151 16-75540

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Sep 2014 15:25:00 -0400

I think the paper is showing why end-to-end DNS privacy is not
practical. Fortunately, that is not the only model on offer.

http://tools.ietf.org/html/draft-hallambaker-privatedns-00

What I propose in Private-DNS is that we begin by taking the DNS
resolution service inside our trust envelope and make it a chosen
trusted service. At present the default configuration is that the
resolver is deemed to be 'untrusted' even though it is obviously
performing a trusted function.

I think this is just common sense regardless of whether we use DNSSEC,
Private-DNS or whatever. Taking a service as important as discovery
from random network locations is just stupid.

What I propose is that all DNS messages be encrypted but the
encryption context be hop-by-hop rather than end-to-end. So if us
choose dns.comodo.com as your resolver service the packets from your
client to dns.comodo.com would be encrypted and requests out from
dns.comodo.com would be encrypted. But dns.comodo.com would see all
your traffic.

The reason for this approach is precisely that we are looking to
prevent traffic analysis rather than provide message layer
confidentiality. So I am not that worried about the resolver service
might defect, provided that I get to choose who provides that service.

What matters to me is that a third party can't intercept that traffic.
In the model I am suggesting the DNS resolution service is going to be
aggressively pre-fetching DNS queries in any case so 99.5% of queries
get answered from cache.

Since I wrote the paper my views on DNS and DNSSEC have evolved. I
still think DNSSEC has a role and it is useful to check records in the
resolver. I don't see the utility in end-to-end DNSSEC except for TLSA
records and other security policy type records.

What matters to me is that my client connects to the intended end
point. I really don't care that it connects to the IP address
specified by the domain name owner. If I want to protect
communications against traffic analysis, I am going to be rewriting
those in any case.