Re: [perpass] DNS confidentiality

[Dan York <[e-mail]>]

Stephane,

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

>> 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

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
[e-mail] <mailto:[e-mail]>   [phone]
Jabber: [e-mail] <mailto:[e-mail]>
Skype: danyork   http://twitter.com/danyork

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