Subject: [DNSOP] DNS privacy draft

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

After discussion with the relevant ADs, it seems this Internet-Draft
is more for this working group. So reading and advices are welcome. I
see several possible outcomes but I let you talk first :-)

Subject: I-D Action: draft-bortzmeyer-dnsop-dns-privacy-00.txt
From: [email-masked]
To: [email-masked]
Date: Wed, 27 Nov 2013 03:35:17 -0800
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : DNS privacy problem statement
	Author(s)       : Stephane Bortzmeyer
	Filename        : draft-bortzmeyer-dnsop-dns-privacy-00.txt
	Pages           : 13
	Date            : 2013-11-27

Abstract:
   This document describes the privacy issues associated with the use of
   the DNS by Internet users.  It is intended to be mostly a problem
   statement and it does not prescribe solutions (although Section 5
   suggests some possible improvments).

   Discussions of the document should take place on the dnsop mailing
   list [dnsop]

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-dns-privacy

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bortzmeyer-dnsop-dns-privacy-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Nov 2013 07:29:05 -0800

On Nov 27, 2013, at 3:40 AM, Stephane Bortzmeyer <[email-masked]> wrote:

> is more for this working group.

Could those relevant ADs maybe say why? If it is because "it's the last WG standing that has 'DNS' in its title", that seems particularly inappropriate in this case. The only possible outcome of people agreeing that there should be more privacy for DNS queries and responses will be protocol changes.

Further, the vast majority of DNS queries are made by applications, not directly by people.

Given those two, the privacy implications of DNS should be discussed (and even acted on, if we are lucky) in the Applications Area.

If I got this all wrong, can you say which part of DNS operations is affected by the privacy issues?

> So reading and advices are welcome. I

My first pass skim results in "this is a very solid starting point; it needs a bit more meat; thank you for doing this as a draft and not just a thread on perpass that will get lost".

--Paul Hoffman

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Nov 2013 16:36:27 +0100

On Wed, Nov 27, 2013 at 07:29:05AM -0800,
 Paul Hoffman <[email-masked]> wrote 
 a message of 29 lines which said:

> The only possible outcome of people agreeing that there should be
> more privacy for DNS queries and responses will be protocol changes.

I disagree. If you read the version -00, you will see that the change
proposed in section 5.2.2 is *not* a change in protocol but an
unilateral action by the resolvers.

Other changes may also be seen as unilateral action not requiring a
protocol change (sending gratuitous queries to defeat traffic
analysis, for instance).

> Further, the vast majority of DNS queries are made by applications,

I do not see your point. When I click on http://www.playboy.com/, the
request may be done by an application but it has certainly a
relationship with a person, the user.

> My first pass skim results in "this is a very solid starting point;
> it needs a bit more meat; 

Can you explain in what parts? I'm willing to write more but I don't
want to increase the size of the draft just to make it more impressive
:-)

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Nov 2013 09:42:16 -0800

> unilateral action by the resolvers.

Ummm, yes, but your message (and the Introduction) made it sound like the emphasis of the draft is on listing the privacy implications, and not the suggested changes to deal with them. Choose a story and stick to it. :-)

> protocol change (sending gratuitous queries to defeat traffic

We haven't gotten into commenting on the stuff in section 5. When we do, I'll point out the futility of gratuitous queries.

> relationship with a person, the user.

"has a relationship" is fairly weak. Rendering the web page returned by a browser query can easily generate 50 DNS queries to places the user has never heard of. Your document needs to cover the privacy implications of DNS requests that were done without intention. Further, the world is more than browsers. The fact that an app I am using is doing a lookup for imap.badplace.org is also important. 

> want to increase the size of the draft just to make it more impressive

Much more emphasis on section 3 ("Actual attacks") would be useful to readers who don't really think in terms of user -> application -> local resolver -> (offsite recursive) -> authoritative(s).

--Paul Hoffman

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 28 Nov 2013 14:25:54 +0100

Hi,

I also heard that this is the place to discuss DNS privacy.

This draft is a protocol, and represents an (interesting) point in the
solution space.  I would refer to Borzmeyer's draft and Koch's draft
for problem space analysis.

http://tools.ietf.org/html/draft-wijngaards-dnsop-confidentialdns-00

It supports opportunistic encryption, i.e. try to encrypt but fallback
to insecure.  This supports deployment immensely, because clean DNS
paths are uncommon.

It supports stateless operation.  It uses UDP.

It supports encryption for stub-to-cache and cache-to-authority.

Best regards,
   Wouter

---

From: "Guangqing Deng" <[email-masked]>
Date: Thu, 28 Nov 2013 22:09:33 +0800

Though bringing privacy protection to the DNS query and response, this method may bring many other negative impacts on DNS system. The DNS resolution latency will be increased due to fetching so-called ENCRYPT RR which makes the DNS zone file bigger. Not onlay the DNS server but also the DNS client have to support encrypt algorithms, which is not a good thing for DNS system. Maybe more considerations are needed to figure out what will happen if this methood is choesn.

Guangqing Deng
CNNIC 

From: W.C.A. Wijngaards
Date: 2013-11-28 21:25
To: dnsop
Subject: [DNSOP] confidentialdns draft

Hi,

Best regards,
   Wouter

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

---

From: Glen Wiley <[email-masked]>
Date: Thu, 28 Nov 2013 09:26:18 -0500

Resolution latency is only affected initially when the resolver must fetch the confkey record, after that initial fetch (until TTL expires) there are no additional packets introduced into the query/response exchange.

Zone file size is not an issue - adding a single key record to support confidential operations is not likely to have a meaningful impact to zone file size based on the impact of DNSSEC adoption.  If every name server adopted support for confidential DNS there would be an impact - this is an inevitable cost of adding a feature like this.

Some of the additional considerations include performance impacts to large scale name servers (both recursive and authoritative).

I agree that this has an impact to the DNS ecosystem, however I suspect that the impact is nearly as low as possible.  An alternative such as implementing TLS would have a far more severe impact on the high volume name servers and would still require client side changes.

On Nov 28, 2013, at 9:09 AM, Guangqing Deng wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
> Hi,
>  
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>  
> iQIcBAEBAgAGBQJSl0RiAAoJEJ9vHC1+BF+NbOcP/03f76fPIp8rkKtjYdjTHbZ7
> qoMFVsIbZ6GqoB77U2w2dtVEirfqLkcBQ5gE1LzLGL/AS4aKVBg7GLAY/qv1o+BM
> YIvoecRd+P+/mzZZtROJbpe3Pp3ktsL9+A4SaChpWBWPR7qCUKGh2R0YWq6hHj0h
> btIOFROGnt/QH0Pho7/0N9UfNBVlc6By8BSwON2kiR9bD+oyCDGxJQ85N03p8FJo
> kVIZM6PtsUHQxhX4rhQec5t/LBu1oXVq5tdVSzjiIYZAcUI9lLfv7f7o1QccAIUF
> YZ/u1OvIp3l6iKNK3eLrimXRu7dFR09aqUcbYD0LNci6g4AY0awPYk2TE5OtQ1Ll
> SHpil/QzKA0V4QPANfZNBV/wL5SitnQuS6fLYkKnsjSED8AUINNLqYttSo+wPEMs
> ReCPI51pyuvL0E/ZkfiKRsfb8qiuFh1OkCLFgJZMVzecLcOvrVfxxf4SNe8Z8i7F
> IzSNikgqSzIK/hQSEMVjk9O+f97/muQw0fCiqGbIS9hUntEwJ90/Ji20dxlz2aj7
> V7nuC4wz53VWHtIYhiDMP2P9Twbh40TmdIf9yWFZzkayryBVwH5gTuU1ZqL2sVc6
> qMolnaKQdTFnM4jAMzfYBuHyUzFTRqG1u9IXLskmBl0tDAOH0cRV4bD6oH8BZd+X
> v//pHQiVWuyMbndChPrm
> =PdRr
> -----END PGP SIGNATURE-----

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 Nov 2013 11:10:39 -0500 (EST)

> I also heard that this is the place to discuss DNS privacy.

This is a generic problem people keep mentioning. We need some new WG
for DNS extensions that's not operations. i was told this was going to
be discussed at dnsops at ietf88 , but it did not happen.

> It supports encryption for stub-to-cache and cache-to-authority.

Asking the LAN's resolver for a specific record (type ENCRYPT to QNAME
".")  seems a bit dangerous.  This is of course completely MITM-able, but
I see no real other way to trust something fundamentally untrustworthy. So
that's okay. But I fear too many of these queries might end up on AS112.
I'd rather see an EDNS advertisement.

For talking to AUTH servers, there is no reason to use QNAME ".". It
could just query for some kind of ENCRYPT record in the zone, which can
be authenticated with DNSSEC, and then becomes resistant to MITM. Even
if that means you once traverse top down to collect the various TLD
ENCRYPT keys.

DNS already has a lot of known plaintext. Having a padding flag that
an attacker can play with seems dangerous too. We've seen too many
padding/oracle attacks. In general, I would prefer that the DNS people
don't invent their own crypto scheme, and use something that has seen a
lot more scrutiny. If (D)TLS is too expensive, than perhaps we should
look around and see how other people solved this in the past. But I
think the "too expensive" is specific to real authoritative servers,
and for instance would never be an issue for a LAN/ISP resolver - a
reason to think of these two problems in two separate documents with
possibly different solutions.

Additionally, encrypting to authoritative servers seems to not make
_that_ much sense to me. Remember, when I need to know www.nohats.ca,
I already tell the .ca nameserver the entire QNAME before I get the
referral. While I see value in LAN/ISP dns cache encryption, I think
encryption of DNS globally is a whole different matter. Encrypting our
individual transactions might not gain us much at all.

This scheme also depends on state between queries. There are dangers
with anycast where specifically the different nodes in different regions
should NOT be using the same crypto key. (which makes storing the key
in DNSSEC harder as well)

Paul

---

From: Glen Wiley <[email-masked]>
Date: Thu, 28 Nov 2013 12:03:27 -0500

> I'd rather see an EDNS advertisement.

If the query is done via validated DNSSEC then that would defeat the MITM attack (this is mentioned in the draft).  One problem with EDNS is that the RFC explicitly prohibits caching the results and I think that being able to cache the records will help avoid superfluous chatter on the network.

> individual transactions might not gain us much at all.

The idea here is that if a TLD and the delegated domains support confidential DNS then you could have a fully confidential query.  I agree that this is a big IF, not quite as big as the DNSSEC signing problem but certainly a significant concern.

> in DNSSEC harder as well)

This is also a problem with multi-node name server footprints running unicast services as well.  Worst case it would result in having to negotiate a secret with multiple name servers.  In practice many load balancers use a hash to deliver traffic to the name servers in large footprints so this might be less problematic that at first appears.  In cases where a load balancer is using a round robin algorithm this has poor characteristics.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 Nov 2013 12:25:38 -0500 (EST)

On Thu, 28 Nov 2013, Glen Wiley wrote:

> If the query is done via validated DNSSEC [...]

You cannot do that. The DNS resolver DHCP gave you is 192.168.1.1. How are
you validating anything? how will you distinguish my rogue 192.168.1.1 from
the real starbucks 192.168.1.1?

That's why the recursive case is so different from the authoritative
case.

Paul

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 29 Nov 2013 09:27:27 +0100

Hi Paul,

So this is another solution, which I want out there in the solution
space because it is stateless.  And there are many things to consider ...

Sending the qname as the zone name in plaintext is not a good idea.
For hop-by-hop encryption there is no need to send more bytes, and it
reveals the zone you are contacting in the clear - which is exactly
what you are trying to hide.

How is the ENCRYPT PAD record different from a TXT record in the sense
of being able to add arbitrary data to a packet?  I obviously did not
want to use TXT.  The reason it is added is that otherwise the
packetsize becomes a highly deterministic value.  We could make it be
full of zeroes (or other deterministic content) ?

On 11/28/2013 06:25 PM, Paul Wouters wrote:
>>> Asking the LAN's resolver for a specific record (type ENCRYPT
>>> to QNAME ".")  seems a bit dangerous.  This is of course
>>> completely MITM-able, but I see no real other way to trust
>>> something fundamentally untrustworthy. So that's okay. But I
>>> fear too many of these queries might end up on AS112. I'd
>>> rather see an EDNS advertisement.
>> 
> You cannot do that. The DNS resolver DHCP gave you is 192.168.1.1.
> How are you validating anything? how will you distinguish my rogue
> 192.168.1.1 from the real starbucks 192.168.1.1?
> 
> That's why the recursive case is so different from the
> authoritative case.

Well in both cases the idea is to use a completely-MITM-able query for
ENCRYPT KEY to start the exchange.  So that this technique can work in
both problem spaces.

At the end-client all you have is DHCP and somebody claims some IP
address is your DNS.  So the key lookup is just like that DHCP
exchange, an initial exchange...

EDNS advertisement.  Well I agree a lot may end up being wasted
queries.  EDNS does not have a TTL, I want cachable resource records,
and the plain new-type-lookup may find it slightly different to bypass
end-client middleboxes than EDNS.  But otherwise this is a
DNS-packet-transportation issue.

Best regards,
   Wouter

---

From: Marc Lampo <[email-masked]>
Date: Fri, 29 Nov 2013 10:28:16 +0100

Hello,

(a reaction on second paragraph of 4. Authenticated Operation, only)

That paragraph states that the ENCRYPT RR can be signed by DNSSEC.
However, I don't think is possible !

A signature is the hash of DNS-data-sent, encrypted with the private key.
But in this case : private key of who ?
!!! not the root-zone, I hope.
? from the domain one is about to sent a query for
   (but the whole idea is to hide that kind of information !)

But since this encryption is really between a DNS client and the DNS server
it is about to query, it should be the "private key of that DNS server".
But that is not what DNSSEC is about.

Hence, I think ENCRYPT RR's cannot be protected by DNSSEC.

Kind regards,

Marc

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 29 Nov 2013 10:40:49 +0100

Hi Marc,

In the draft it says to store the ENCRYPT RR in this case at
ns.example.com.  It would then be signed with the ZSK DNSKEY for
example.com, with normal DNSSEC chain of trust.

But again, the authenticated operation is not the main aim of this draft.

Best regards,
   Wouter

On 11/29/2013 10:28 AM, Marc Lampo wrote:
> A signature is the hash of DNS-data-sent, encrypted with the
> private key. But in this case : private key of who ? !!! not the
> root-zone, I hope. ? from the domain one is about to sent a query
> for (but the whole idea is to hide that kind of information !)
> 
> But since this encryption is really between a DNS client and the
> DNS server it is about to query, it should be the "private key of
> that DNS server". But that is not what DNSSEC is about.
> 
> On Thu, Nov 28, 2013 at 2:25 PM, W.C.A. Wijngaards
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi,
> 
> This draft is a protocol, and represents an (interesting) point in
> the solution space.  I would refer to Borzmeyer's draft and Koch's
> draft for problem space analysis.
> 
>  It supports opportunistic encryption, i.e. try to encrypt but
> fallback to insecure.  This supports deployment immensely, because
> clean DNS paths are uncommon.
> 
> Best regards, Wouter
> _______________________________________________ DNSOP mailing list 
> [email-masked] <mailto:[email-masked]>

---

From: Marc Lampo <[email-masked]>
Date: Fri, 29 Nov 2013 11:53:16 +0100

I think the draft is very unclear on this (DNSSEC) point -
at least I don't find this statement about the ENCRYPT RR being signed by
with the private key of example.com.

Anyway : a RRSIG RR holds the name of the domain that signed in clear text.

Kind regards,

Marc

On Fri, Nov 29, 2013 at 10:40 AM, W.C.A. Wijngaards <[email-masked]>wrote:

> iQIcBAEBAgAGBQJSmGEgAAoJEJ9vHC1+BF+NM2MP/3eUycaHd5l3eywpaevDj9HX
> z1E7b3+ebH/cLGMAR0KD940aYw7xYlDG/6b83hqeEVdQVxD7ga6VUcOPImbfOX7o
> h8AwJif9mFsGaPCFwxMiaGnF/NmdPAt+C9KNB9fNuEKWIGZbNCDjms7KpC6FDTua
> JJ6lPLnuuWCiIUEiKbsjOEl2sJ2y8XV48+jvKuYYXc3EOL2tF0+/BiclXSB7Jw3y
> YZ9caUU24teNVWU6g24SflxX/WdPRdSGAGFLYmFc2NEWrrXVvhmpmVGl9le/W6Lc
> /pycV+yQZEK7NXP1KrAx28GSjlaJ8duKAXgAk8zsw7bEiqMPpzzNx7fp9pkXGbRy
> KoEKMiOdnZGnqhIAx4H32ookjWuMnZFGY2FeKL0D3YsR9AgkuVbc+ga7MODwg6JH
> 62WADFn8DZCzbNOGIc7375FiVpogCZfPOP5BjrN1VTWL6r3jxAClWZABhQ+gEfCt
> 34+cxl83FaznxkvhK5DBQoQQmVdcitKOywkKgTlCPAd+gXSJ7SzzxrlcC5Vz0Py5
> xoRYjPOnFC/Fz3rrLzhFomsISftKeIsvuCRlqsnd/FMzkqwxhUtZuKlUYEJs5qbF
> kxv39xcDrAlbpyYvK5o14LKzto9+7/zpWI/js/0A1gWaq62mbpoq67J+UbgYCASk
> Ilm/xu2QrnoGLsAS9R3q
> =8SfA

---

From: "Guangqing Deng" <[email-masked]>
Date: Sat, 30 Nov 2013 09:18:29 +0800

And there is also public key rolling issue  in this scheme just as the zone KSK rolling in DNSSEC. More consideration is needed to handle this issue since the private key of a DNS domain may be leaked.

Guangqing Deng
CNNIC 

From: Marc Lampo
Date: 2013-11-29 18:53
To: W.C.A. Wijngaards
CC: [email-masked] WG
Subject: Re: [DNSOP] confidentialdns draft
I think the draft is very unclear on this (DNSSEC) point -

Kind regards,

Marc

On Fri, Nov 29, 2013 at 10:40 AM, W.C.A. Wijngaards <[email-masked]> wrote:

Hi Marc,

Best regards,
   Wouter