Subject: Re: [perpass] DNS confidentiality

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 11 Nov 2013 13:10:27 +0100

On Wed, Sep 25, 2013 at 02:40:59PM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 13 lines which said:

> May be starting with the more modest but certainly useful "DNS
> privacy considerations" Internet-Draft? Such a document, just
> documenting the problem, would be a good idea, IMHO.

Done. 
http://tools.ietf.org/html/draft-bortzmeyer-perpass-dns-privacy

---

From: "Wiley, Glen" <[email-masked]>
Date: Mon, 11 Nov 2013 19:27:25 +0000

Stephane,

Thanks for taking the time to capture this issue in a draft. I am very
supporting of providing a means to make DNS confidential.

A few comments from a reviewers perspective:

Section 3.2:

I realize that this is obvious, but it might be worth noting that there is
often (typically) a network connection made to the subject of a DNS query
sent from a stub resolver.  For example after sending a query for
www.example.com I am likely to make a connection via TCP to the address
returned.  This fact reduces the value of obscuring DNS queries at the
last mile unless the most aggressive measures are taken (a VPN or tunnel).
If an eavesdropper can dump traffic on the wire then they will see
outbound connections to www.example.com and so it doesn't really matter
whether they were able to see the DNS query.

Section 3.3.3:

While I agree with the sentiments in this section, is this in scope for
this draft?  This feels a little more like a reprise of arguments in favor
of DNSSEC which does not address privacy at all.

Section 4:

There is enough overlap between sections 4 and 3.3 that I would combine
section 4 and section 3.3 to address the problem of properly handling
packet traces and captured DNS traffic in a way that protects end user
privacy.

Section 6.1

It feels as though this section dives into the solution rather than the
problemŠ.something that needs to be done, but it feels out of scope for
this draft.  This could be addressed by changing the abstract of the draft
or by reducing the content in this section.

-- 
Glen Wiley
KK4SFV

Sr. Engineer
The Hive, Verisign, Inc.

On 11/11/13 7:10 AM, "Stephane Bortzmeyer" <[email-masked]> wrote:

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

---

From: Ted Hardie <[email-masked]>
Date: Tue, 12 Nov 2013 08:12:13 -0800

Some comments in-line.

> whether they were able to see the DNS query.
While I agree it reduces the value, it doesn't eliminate the value.  One
reason for this is services which provide different content at the same IP,
often depending on the HTTP Host: header to disambiguate among the
resources available.  The DNS query tells you which resource was the target
even if the HTTP flow was protected by TLS.  The same is true when someone
uses a stub resolver to query for DNS records using a local network before
passing the traffic through a VPN (there are a variety of configurations in
which this can happen).

regards,

Ted

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Nov 2013 17:16:13 -0800

On 12 November 2013 08:12, Ted Hardie <[email-masked]> wrote:
> The DNS query tells you which resource was the target even if the HTTP flow
> was protected by TLS.

In practice, since server name indication is sent in the clear, even
this doesn't help.  Unless you are running a browser from 2001, you
are sending SNI.

That said, SNI may be pushed into an encrypted payload in TLS 1.3.
The challenge there is that servers often use SNI to select what
credentials to offer.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Nov 2013 01:32:19 +0000

> The challenge there is that servers often use SNI to select what

Actually, I think that's maybe interestingly illustrative of some
of the non-crypto issues we face.

The converse argument was just made on the TLS list yesterday to
the effect that there's no point in TLS 1.3 (or a TLS 1.2 extension)
encrypting SNI because its the same as the obviously cleartext DNS
query in many cases. (Not in all cases being due to VPNs, but that's
not the point.)

I think there are at least two credible choices for how one regards
attempts to counter traffic analysis: 1) give up, its too hard, and
going to get worse no matter what we try do, or 2) try chip away at
the problem as and when we can in the hope we eventually do make it
better.

There are probably more as well, but I'm for (2) even though I can
understand those who think (1) is much more practical. Or maybe I
just hate giving up;-)

S.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Nov 2013 21:48:57 -0500

On Nov 12, 2013, at 8:32 PM, Stephen Farrell <[email-masked]> wrote:
> query in many cases.

That's a terrible argument.   Then every eavesdropping issue becomes a chicken-and-egg problem, because nobody is willing to go first.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Nov 2013 03:03:51 +0000

Hey Ted,

On 11/13/2013 02:48 AM, Ted Lemon wrote:
>> the effect that there's no point in TLS 1.3 (or a TLS 1.2
>> extension) encrypting SNI because its the same as the obviously
>> cleartext DNS query in many cases.
> 
> That's a terrible argument.   Then every eavesdropping issue becomes
> a chicken-and-egg problem, because nobody is willing to go first.

Well, I wouldn't say terrible, but it is unfortunate, yes.

In this case, there's a (presumed but realistic) tension between
the relative timing of DNS and TLS updates, the absence of each
of which makes the occurrence of the other less likely. And that
combination makes it less likely that we (the IETF) are motivated
to try "fix" either.

And all that is replicated up and down the stack - "why should
I make application layer privacy better when its so bad at the
RF layer with fingerprinting" is an argument that I have seen
made in IETF discussion.

But again, I'm for trying to do it all better, to the extent we
can and I'm not for giving up.

S.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 13 Nov 2013 05:22:29 +0000

> That's a terrible argument.   Then every eavesdropping issue becomes a chicken-and-egg problem, because nobody is willing to go first.

I'm one of those that made that argument. I do think we should fix this in TLS, but realistically, browsers are going to continue sending SNI in the clear for at least another 10 years. Yes, we should fix this now, because whenever we start, that's when the 10-year countdown begins. The same is true for any modification to DNS, except the timeframe is likely to be even longer.

Yoav

[1] http://www.ietf.org/mail-archive/web/tls/current/msg10555.html

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 12 Nov 2013 23:29:12 -0800

> I'm one of those that made that argument. I do think we should fix this in
TLS, but realistically, browsers are going to continue sending SNI in the 
> clear for at least another 10 years. Yes, we should fix this now, because
whenever we start, that's when the 10-year countdown begins. The same is >
true for any modification to DNS, except the timeframe is likely to be even
longer.

Even if TLS is not fixed, there is still value in improving DNS privacy.
Stephane makes the point in his draft:

   What also makes the DNS traffic different is that it may take a
   different path than the communication between the initiator and the
   recipient.  For instance, an eavesdropper may be unable to tap the
   wire between the initiator and the recipient but may have access to
   the wire going to the resolver, or to the authoritative name servers.

Suppose that a host sends a query for
"_bittorrent-tracker._tcp.domain.example.com." If it does not have a cached
copy of the NS record for "example.com," the query will go the ".com"
server. Because the query carries the entire QNAME, anyone who eavesdrop on
the TLD server would learn that the host is attempting to contact a bit
torrent server at "domain.example.com." They would learn that even if they
are not able to eavesdrop on the direct path between the host and
"domain.example.com."

Now suppose that instead of sending a query with the full QNAME, the host
just sends to the ".com" server a query for the NS record of "example.com."
Once it receives the response, the host can send the full query directly to
"ns.example.com." Clearly, that too can be eavesdropped, but only if the
eavesdropper has a tap on the direct path between the client and the bit
torrent server. And if it has such a tap, it will find anyhow that there is
TCP-IP traffic between the host and the bittorrent server at
"domain.example.com," which means that parsing the DNS query would not
provide extra information.

So we have here a simple way to prevent leakage of information. It can
actually be implemented unilaterally by resolvers, and does not require a
change in the DNS protocol. It does require that the resolver somehow learn
the "zone cuts," but that is not impossible to learn.

-- Christian Huitema

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Nov 2013 10:11:57 +0100

On Tue, Nov 12, 2013 at 11:29:12PM -0800,
 Christian Huitema <[email-masked]> wrote 
 a message of 51 lines which said:

> It does require that the resolver somehow learn the "zone cuts," but
> that is not impossible to learn.

Specially since every DNSSEC-validating resolver has to do it, anyway
(to know where to find the DS and the DNSKEY). So, in practice, BIND
and Unbound has this code for a long time.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Nov 2013 10:33:21 +0100

On Tue, Nov 12, 2013 at 09:48:57PM -0500,
 Ted Lemon <[email-masked]> wrote 

> a chicken-and-egg problem, because nobody is willing to go first.

Indeed. That's an argument that completely denies the point of
engineering: "Finding good-enough solutions to actual problems". We do
not hope to design perfect solutions. Leakages will always happen. But
we try to have *less* leaks, in order, not to make surveillance
impossible but, as Bruce Schneier said during the plenary, to make
mass surveillance *very* expensive for the spy. Surveillance requires
gathering data from several places and making sense of it. The less
data, the harder it becomes.

Of course, we should not spend too much efforts securing the door when
the window is wide open. But each of us should spend efforts on "his"
part of the Internet. As a DNS guy, I plan to make surveillance using
the DNS harder and more expensive. I'm confident the TLS guys will do
the same.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Nov 2013 10:49:06 +0100

On Mon, Nov 11, 2013 at 07:27:25PM +0000,
 Wiley, Glen <[email-masked]> wrote 
 a message of 67 lines which said:

> I realize that this is obvious, but it might be worth noting that
> there is often (typically) a network connection made to the subject
> of a DNS query sent from a stub resolver.  For example after sending
> a query for www.example.com I am likely to make a connection via TCP
> to the address returned.  This fact reduces the value of obscuring
> DNS queries

That's one of the reasons that I mentioned other practices such as
having a local resolver (with caching) to limit the number of actual
outgoing queries. When it comes for privacy, it is very unlikely that
*one* technical solution will plug all the leaks. We have to deploy a
consistent set of anti-surveillance measures.

Another thing, not yet mentioned in the draft, would be to send dummy
queries from time to time, requests you're not interested in, just to
blur the patterns.

> then they will see outbound connections to www.example.com and so it
> doesn't really matter whether they were able to see the DNS query.

Read the draft again (section 3.2). For instance, the manager of the
TLD .example sees the DNS requests coming in his name servers but
typically cannot tap the TLS traffic to www.something.example.

> this draft? 

Yes, it is. We have seen already malwares who modifies the DNS
resolvers to a server which, apparently does not lie. The only
explanation I can find is that people want to spy on DNS traffic.

> problem.

At the beginning of this draft, it was only about problem
statement. Some people feared it would not be taken seriously if it
never mentioned at least possible solutions. (After all, knowing a
problem for which there is no solution is depressing.)

May be in the future, this draft should be split in two, problem
statement and best practices to limit DNS leakage. But, IMHO, it is
too early in the discussion to say so.

In practice, solutions would probably require several RFC since some
are only practices (having a local caching resolver), some require
change in software but not in protocol (sending only NS queries to the
authoritative servers) and some require new protocols (encrypting DNS
traffic).

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 13 Nov 2013 13:11:08 +0100

> typically cannot tap the TLS traffic to www.something.example.

JFTR with my TLD hat on I fully support Stephane's draft.  Every little bit counts and neither chicken-and-egg nor too-long-to-deploy should not stop us from making security or privacy better.

And the less information I see on TLD DNS servers the better.  I (as an TLD server operator) don't want to know all the information since that makes me vulnerable to attacks and/or legal wiretapping.

The SNI/TLS cleartext should motivate people to fix TLS and not to hinder the improvements in DNS area.

O.
--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 13 Nov 2013 13:00:10 +0000

Just to be clear - I support the draft in principle.  My comments are
intended to help refine the document.
-- 
Glen Wiley
KK4SFV

Sr. Engineer
The Hive, Verisign, Inc.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Nov 2013 09:05:20 -0500

On the subject of SNI itself.... lack of support for SNI for a number of
legacy browsers still in use means that few sites using SSL can do it any way
other than the one-IP(port) per certificate.  This is a tragedy in the IPv4
world, but really hardly merits even a shrug in an IPv6 world.

On the other hand, with a 1:1 mapping between IPv6 and DNS name (and
certificate), you don't need to see/capture the transport or session(ssl)
layer at all to know do the traffic analysis.  So one gets the traffic
analysis at the DNS name from the netflow (aka "Pen Registry") records
without eating any multi-gigabite firehoses.

If TLS could become more IKE-like, leaving the SNI and the authentication
until after the PFS (maybe it can do this already now), then traffic analysis
would be defeated by putting as many sites on the same IP address as
possible.   
(Possibly, this also interacts poorly with some of the various netnanny
software, which has unfairly prevented teens from learning enough to protect
themselves from STD in the name of protecting them from pr0n. )

My take is that any mechanism (legal and technological) which keeps the
middle boxes on a need to know basis only,  is good.  It might not prevent
traffic analysis, but it does help maintain the end to end.
(Imagine the state of the world of TCP cryptographically secured the port
numbers, or if HTTPS had done that, and NAPTs simply couldn't have worked)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Nov 2013 09:32:35 -0500

> I'm one of those that made that argument. I do think we should fix this in TLS, but realistically, browsers are going to continue sending SNI in the clear for at least another 10 years. Yes, we sho…

That doesn't sound *quite* like what I heard Stephen say, and I don't disagree with it, although I don't agree either—it's hard to predict what browser people will do, and ten years is a long time in the browser business.   So you might as well fix the spec, and see what happens.

---

From: Dan York <[email-masked]>
Date: Wed, 13 Nov 2013 15:32:06 +0000

Stephane,

>http://tools.ietf.org/html/draft-bortzmeyer-perpass-dns-privacy

Excellent draft!  Thank you for taking the time to write this and I very
much support the draft and the material you've written.

A few comments:

In section 3.2, "On the wire", it might be worth expanding a bit to note
that the attack surface between the stub resolver and the caching resolver
can vary widely depending upon how the end user's computer is configured.
It seems to me there are typically 4 different locations that may be
configured as the caching resolver.  Here is some draft text for your
consideration:
----
1. Resolver at the ISP - For most residential users and potentially other
networks the typical case is for the end user's computer to be configured
(typically automatically through DHCP) with the addresses of the DNS
resolver at the ISP.  The attack surface for on-the-wire attacks is
therefore from the end user system across the local network and across the
ISPs
network to the ISP's resolvers.

2. Resolver at the local network edge - For many/most enterprise networks
and for some residential users the caching resolver may exist on a server
at the edge of the local network.  In this case the attack surface is the
local network.  Note that in large enterprise networks the DNS resolver
may not be located at the edge of the local network but rather at the edge
of the overall enterprise network. In this case the enterprise network
could be thought of as similar to the ISP network referenced above.

3. Resolver at a public DNS service - Some end users may be configured to
use public DNS resolvers such as those operated by Google's Public DNS or
the OpenDNS team. The end user may have configured their machine to use
these DNS resolvers themselves - or their ISP may choose to use the public
DNS resolvers rather than operating their own resolvers.  In this case the
attack surface is the entire public Internet between the end user's
connection and the public DNS service.

4. Resolver on the end user's computer - In a small number of cases,
individuals may choose to operate their own DNS resolver on their local
machine. In this case the attack surface for the stub resolver to caching
resolver connection is limited to that single machine.
----

There could be additional cases but those are what came to my mind.  From
an attack perspective it's obviously much harder to do an on-the-wire
attack between a stub resolver and caching resolver against someone
running a caching resolver on the edge of their local network (or on their
machine) than it is against someone using a public DNS service.

In some of Geoff Huston's recent DNSSEC measurements that he's presented
at various events, one interesting aspect was the very high percentage of
people in some regions who were using Google's Public DNS servers.  I seem
to recall at Geoff's presentation at the IEPG meeting in Berlin in July he
mentioned that it seemed like the major ISPs in some countries had all
decided to use Google's servers vs running their own.

In section 3.3.2 you state:
----
As of today, all the instances of one root name server, L-root, receive
together around 20 kq/s.

----
I can't find "kq/s" defined anywhere in the draft and so you might want to
expand this here.  I'm assuming you mean "kilo-queries per second",
correct?

In section 6.1 about possible solutions to "On the wire" attacks, I would
suggest perhaps putting all the text into a 6.1.1 titled "Encryption" and
then creating a 6.1.2 called perhaps "Reducing the attack surface" with
text along these lines (assuming text similar to what I wrote above is
incorporated into section 3.2):

----
One mechanism to potentially mitigate on the wire attacks between stub
resolvers and caching resolvers is to determine if the network location of
the caching resolver can be moved closer to the end user's computer.  As
noted earlier in section 3.2, if an end user's computer is configured with
a caching resolver on the edge of the local network, an attacker would
need to gain access to that local network in order to successfully execute
an on the wire attack against the stub resolver.  On the other hand, if
the end user's computer is configured to use a public DNS service as the
caching resolver, the attacker needs to simply get in the network path
between the end user and the public DNS server and so there is a much
greater opportunity for a successful attack.  Configuring a caching
resolver closer to the end user can reduce the possibility of on the wire
attacks.
----

Or something like thatŠ

I enjoyed your section 7! :-)

I have a few other editorial nits regarding wording that I'll send you
privately.

AgainŠ great draft. Thanks for taking the time to put it together.

Dan

-- 
Dan York
Senior Content Strategist, Internet Society
[email-masked] <mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked] <mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 Nov 2013 08:16:55 -0800

> The challenge there is that servers often use SNI to select what

True; I'd been thinking about the blogspot-style use cases where you get an
initial negotiation at one name followed by a large set of alternate names,
but that's not the common case.  The VPN case is still an issue, though.

Having read through the rest of the thread, pushing SNI into the encrypted
portion of TLS in 1.3 seems like a good thing to do.

Ted

---

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 13 Nov 2013 16:21:26 +0000

While I certainly support the idea of confidential DNS, I wonder whether it is a good idea to impose the overhead involved in TLS on the high volume name servers?
--
Glen Wiley
KK4SFV
Sr. Engineer
The Hive, Verisign, Inc.

From: Ted Hardie <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 13, 2013 11:16 AM
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: "Wiley, Glen" <[email-masked]<mailto:[email-masked]>>, perpass <[email-masked]<mailto:[email-masked]>>, Stephane Bortzmeyer <[email-masked]<mailto:[email-masked]>>, Andy Wilson <[email-masked]<mailto:[email-masked]>>, Stephen Farrell <[email-masked]<mailto:[email-masked]>>
Subject: Re: [perpass] DNS confidentiality

On Tue, Nov 12, 2013 at 5:16 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

True; I'd been thinking about the blogspot-style use cases where you get an initial negotiation at one name followed by a large set of alternate names, but that's not the common case.  The VPN case is still an issue, though.

Having read through the rest of the thread, pushing SNI into the encrypted portion of TLS in 1.3 seems like a good thing to do.

Ted

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Nov 2013 22:28:17 +0100

On Wed, Nov 13, 2013 at 04:21:26PM +0000,
 Wiley, Glen <[email-masked]> wrote 
 a message of 150 lines which said:

> While I certainly support the idea of confidential DNS, I wonder
> whether it is a good idea to impose the overhead involved in TLS on
> the high volume name servers?

First, it may not be TLS. I mention dnscrypt and there is also at
least one (not published yet) proposal to encrypt DNS without TLS (or
DTLS).

Second, I do not think we want to impose anything ("MUST encrypt all
queries and MUST accept encrypted queries"...) My vision is that some
servers will adopt encryption and not all. The resolvers will have to
decide (local policy) what to do if the remote server does not support
encryption.

This approach seems the only realistic one, for incremental
deployment. An interesting consequence is that the end-user will have
trouble knowing if his queries are encrypted or not (specially if his
resolver uses a forwarded).

---

From: "Wiley, Glen" <[email-masked]>
Date: Thu, 14 Nov 2013 19:49:39 +0000

>least one (not published yet) proposal to encrypt DNS without TLS (or

Thanks - I had TLS on the brain while I was reading.

>decide (local policy) what to do if the remote server does not support

The idea of making it opportunistic makes sense to me.

>resolver uses a forwarded).

I agree.  If he uses a secure transport then one way for the end user to
know whether the queries are encrypted is to handle the iteration himself
and hit the authoritative servers directly rather than query a recursive
resolver.  In order to do anything more definite we would need to alter
the DNS protocol.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Nov 2013 10:09:35 +0100

On Wed, Nov 13, 2013 at 03:32:06PM +0000,
 Dan York <[email-masked]> wrote 
 a message of 117 lines which said:

> I very much support the draft

By the way, the draft talks only about *passive* attacks, in line with
the perpass "charter", and therefore does not mention DNSSEC.

But evil projects like QUANTUM and FOXACID
<https://www.schneier.com/blog/archives/2013/10/how_the_nsa_att.html>
are known to use *active* attacks to make mass surveillance
easier. Against these attacks, DNSSEC may have a role. Good summary
(and plead for DNSSEC deployment) in
<http://www.wired.com/opinion/2013/11/this-is-how-the-internet-backbone-has-been-turned-into-a-weapon/>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Nov 2013 12:45:35 +0100

On Mon, Nov 11, 2013 at 01:10:27PM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 

> http://tools.ietf.org/html/draft-bortzmeyer-perpass-dns-privacy

Now moved to dnsop, per request of the ADs

http://tools.ietf.org/html/draft-bortzmeyer-dnsop-dns-privacy

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Nov 2013 15:10:57 +0000

> http://tools.ietf.org/html/draft-bortzmeyer-dnsop-dns-privacy

Cool. Another one triaged:-)

S.