Subject: [dns-privacy] Agenda for DPRIVE in Dallas.

From: Warren Kumari <[email-masked]>
Date: Tue, 3 Feb 2015 11:01:23 -0500

Hi all,

The Dallas meeting is approaching, and we'd like to start getting the
agenda organized.
Please send us requests for time, etc.

We have not made nearly as much progress since Hawaii as we'd hoped
for / expected - sorry. Tim and I hope to chat early next week to
discuss how to move things forward...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Feb 2015 13:04:17 -0500

> discuss how to move things forward...

The key for me is are we going to design a protocol that is designed to be
part of the Internet core and replace legacy DNS for the client-resolver
loop or are we just going to produce a protocol that makes privacy possible
when needed.

My criteria for the two approaches are very different. If we are doing core
architecture then what matters is the absolute size of the library needed
to implement the DNS-Privacy protocol. If on the other hand we are just
trying to provide additional privacy for Web users then what matters is the
delta between the standard Web stack and the new.

Since writing my original Private-DNS protocol, I have made some
improvements that I should be able to share in draft form soon. In
particular, progress in the ECC debate in CFRG means I am no longer so
worried about putting public key crypto in the client-resolver loop. But I
still want to be able to insulate the hosts performing DNS lookup from
arbitrary Internet users attempting to connect to them. So I still want to
separate the process of validating and credentialing an account at a DNS
resolver and making query transactions.

I have also made some progress on the problem of using private-DNS in
situations where strong privacy guarantees are required but I am not yet
ready to disclose these. What I can say now is that if people want to have
maximum flexibility in making DNS clients effectively anonymous to
resolvers, then the preferred approach is to decouple the application of
encryption and authentication to DNS packets from the key negotiation
interaction.

For obvious reasons, there is a limit to the extent to which we can produce
privacy protection protocols in a public process such as IETF that are
going to be effective in environments where the network is controlled by a
hostile government. So rather tip our hand to the dictators, I would prefer
to produce a protocol with one component that can be swapped out to make
such changes and clearly mark it as such.

---

From: "Guangqing Deng" <[email-masked]>
Date: Thu, 12 Feb 2015 16:31:19 +0800

Hi, what you have done on DNS privacy protection sounds attractive and interesting. What we concern usually is the induced DNS resolution delay, and is it convenient for you to reveal some numbers about the extra delay caused by your so-called original Private-DNS protocol compared with normal DNS resolution delay?

Guangqing Deng
CNNIC 
 
From: Phillip Hallam-Baker
Date: 2015-02-04 02:04
To: Warren Kumari
CC: [email-masked]
Subject: Re: [dns-privacy] Agenda for DPRIVE in Dallas.

The key for me is are we going to design a protocol that is designed to be part of the Internet core and replace legacy DNS for the client-resolver loop or are we just going to produce a protocol that makes privacy possible when needed.

My criteria for the two approaches are very different. If we are doing core architecture then what matters is the absolute size of the library needed to implement the DNS-Privacy protocol. If on the other hand we are just trying to provide additional privacy for Web users then what matters is the delta between the standard Web stack and the new.

Since writing my original Private-DNS protocol, I have made some improvements that I should be able to share in draft form soon. In particular, progress in the ECC debate in CFRG means I am no longer so worried about putting public key crypto in the client-resolver loop. But I still want to be able to insulate the hosts performing DNS lookup from arbitrary Internet users attempting to connect to them. So I still want to separate the process of validating and credentialing an account at a DNS resolver and making query transactions.

I have also made some progress on the problem of using private-DNS in situations where strong privacy guarantees are required but I am not yet ready to disclose these. What I can say now is that if people want to have maximum flexibility in making DNS clients effectively anonymous to resolvers, then the preferred approach is to decouple the application of encryption and authentication to DNS packets from the key negotiation interaction.

For obvious reasons, there is a limit to the extent to which we can produce privacy protection protocols in a public process such as IETF that are going to be effective in environments where the network is controlled by a hostile government. So rather tip our hand to the dictators, I would prefer to produce a protocol with one component that can be swapped out to make such changes and clearly mark it as such.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 14 Feb 2015 17:16:42 +0100

On Tue, Feb 03, 2015 at 11:01:23AM -0500,
 Warren Kumari <[email-masked]> wrote 

> Please send us requests for time, etc.

I don't know if it requires time in Dallas but, in Honolulu, there
were many approvals of the current state of
draft-ietf-dprive-problem-statement. I suggest that it may be ready
for Working Group Last Call very soon (version -02 will be published
on monday, but if you're impatient, you can see it at
<https://github.com/bortzmeyer/my-IETF-work/tree/master/draft-ietf-dprive-problem-statement>).

There is on Github one open issue about proper casing for entities
like Stub Resolver (or stub resolver)
<https://github.com/bortzmeyer/my-IETF-work/issues/3>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 16 Feb 2015 08:05:03 +0800

> <https://github.com/bortzmeyer/my-IETF-work/issues/3>

Yup. As far as I remember this was close to being cooked.
I seem to remember Allison was going to send some comments, privacy
terminology - not sure if that happened?

W

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 16 Feb 2015 10:40:11 +0100

On Mon, Feb 16, 2015 at 08:05:03AM +0800,
 Warren Kumari <[email-masked]> wrote 

> terminology - not sure if that happened?

If it did, I missed it. Allison?

---

From: Warren Kumari <[email-masked]>
Date: Tue, 17 Feb 2015 07:45:00 +0800

>> <https://github.com/bortzmeyer/my-IETF-work/tree/master/draft-ietf-dprive-problem-statement>).

Looking at the changelog / blame in GitHub it seems that you have
already received and incorporated substantial feedback.
I have some comments / nits in an edit buffer that I hope to send over
tonight, and then, after -02 is published (and we've given Allison a
day or two to respond (today is a public holiday in the US)) I think
we can start WGLC.

W

---

From: "Mankin, Allison" <[email-masked]>
Date: Tue, 17 Feb 2015 01:47:37 +0000

I had indeed forgotten to do this review.  However, here it is now, with
thanks for the kind pings.  Overall, as I said in Honolulu, I think this
is in good shape.  It¹s a bracing overview of the attack surface against
privacy, what the Items of Interest (IOI in RFC 6873 terms) are, and in
what ways pervasive surveillance attack can expose them.

Section 1 - 

"also called caching resolver or full resolver or simply resolver
recursive name server"
Editorial:  s/resolver recursive name server/recursive resolver/

"Because there is typically no caching in the stub resolver, the recursive
resolver, unlike the authoritative servers, sees everything."
Comment: This isn¹t quite absolute.  The DNS caches in some browsers may
impact the data collection.  Also, in some enterprises, a load balancer or
other intermediary between the stubs and the recursive might affect how
complete the data collection at a particular recursive is.

"It should be noted that DNS recursive resolvers sometimes forward
requests to bigger machines, with a larger and more shared cache, the
forwarders (and the query hierarchy can be even deeper, with more than two
levels of recursive resolvers)."
Comment: there are forwarders before recursive resolvers as well.

Section 2 -

"Privacy risks for the holder of a zone (the risk that someone gets the
data) are discussed in [RFC5936 <https://tools.ietf.org/html/rfc5936>]."
Comment:  the avoidance of enumeration by NSEC3 (RFC 5155) pertains to
this as well.  This point can be added to the discussion of RFC 5936 in
section 2.1 as well.

Section 2.2 - 

"A note about IP addresses: there is currently no IETF document which
describes in detail the privacy issues of IP addressing."
Comment: This overlooks RFC 4941, which is all about the privacy issues of
IP addresses (IPv6).  It doesn¹t say anything about IPv4 addresses, but I
think it¹s still worthy of note here.

Section 2.3 -

"Since this also is a reconnaissance technique for subsequent cache
poisoning attacks, some counter measures have already been developed and
deployed."
Comment: A reference would be helpful here.

Section 2.5 - 

"for research purposes [ditl]²
Comment: This reference to DITL goes to a 2002 paper that came before the
present arrangement at DNS-OARC. Researchers in DNS-OARC are conscious
that DNS data is sensitive and DNS-OARC takes some care to ensure that the
data is not redistributed and is not open-acess.  I think this comes
through clearly enough in the 2008 paper by Sebastian, Duane, kc and
Marina:  
http://www.sigcomm.org/sites/default/files/ccr/papers/2008/October/1452335-
1452341.pdf

Section 2.5.2 - 
"The root sees the traffic for all the TLDs (and the huge amount of
traffic for non-existing TLDs), but a large TLDs has less caching before
it.²
Comment: this sentence is hard to understand, even after s/a large TLDs/a
large TLD/.  What is meant by ³less caching before it²?  Is the
distinction that (large) TLDs see more cache misses compared with root? A
point that could be added is that there are many unpopular domain names in
any TLD and these will usually be cache misses, so information from those
queries is available to TLDs.

"As of today, all the instances of one root name server, L-root, receive
together around 20,000 queries per second.  While most of it is junk
(errors on the TLD name), it gives an idea of the amount of big data which
pours into name servers."

Comment: this needs a reference. If it¹s helpful, the statistics for A and
J roots (in queries per day but similar when you convert to queries per
second) are at [a|j].root-servers.org/metrics.html

"Also, it seems (TODO: actual numbers requested) that there is a strong
concentration of authoritative name servers among ³popular" domains (such
as the Alexa Top N list).  With the control (or the ability to sniff the
traffic) of a few name servers, you can gather a lot of information.²
Comment: Is this based on the paper by Bala Krishnamurthy and Craig Wills
in IMC 2006?, ³Generating a Privacy Footprint on the Internet²
http://www2.research.att.com/~bala/papers/pfp-imc06.pdf?

Section 3 - 

"It [passive dns] is an example of a privacy issue even when no source IP
address is kept.²

Comment: could you elaborate?  In fairness to the Passive DNS paper (and
usage of DNS monitoring for things like DDoS mitigation), operators do
aggregation and other things to try to limit the exposure of individuals.
So this sentence is a bit abrupt considering the efforts made.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 18 Feb 2015 21:31:58 +0100

On Tue, Feb 17, 2015 at 01:47:37AM +0000,
 Mankin, Allison <[email-masked]> wrote 
 a message of 128 lines which said:

> However, here it is now,

Many thanks, a lot was integrated in commit
16c6ee5e519716142d56fb59023f01e36f195f10
<https://github.com/bortzmeyer/my-IETF-work/commit/16c6ee5e519716142d56fb59023f01e36f195f10>
and will appear in -02.

> complete the data collection at a particular recursive is.

True but I hesitate. Since RFCs have no footnotes, adding correct
precisions like this one always risk bloating the text of the future
document. Any editorial guidance from experienced RFC authors?

> Comment: there are forwarders before recursive resolvers as well.

"forwarder" seem poorly defined. See draft-hoffman-dns-terminology-01
and
<http://mailarchive.ietf.org/arch/msg/dnsop/SDTdFyl7Fg1iMxX734tOPNz94mY>

> IP addresses (IPv6).

May be rather
<http://www.iab.org/wp-content/IAB-uploads/2011/07/IPv6-addresses-privacy-review.txt>,
which is broader?

> "Since this [cache snooping] also is a reconnaissance technique for
> subsequent cache poisoning attacks, some counter measures have
> already been developed and deployed."

Agreed. WG, any suggestion?
 
> Comment: this needs a reference. 

ICANN Web server says "The website you are trying to view is currently
undergoing maintenance" so I will search a reference later.

> http://www2.research.att.com/~bala/papers/pfp-imc06.pdf?

No. It's an unpublished survey.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 19 Feb 2015 09:04:23 +0100

On Wed, Feb 18, 2015 at 09:31:58PM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 

> No. It's an unpublished survey.

Now published but only in french. Interesting Internet governance
issue :-) Can I add a reference to a document in non-english?

 https://blog.imirhil.fr/vie-privee-et-le-dns-alors.html

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Feb 2015 08:41:06 -0800

> issue :-) Can I add a reference to a document in non-english?

Yes. And you should. (And I say this as someone who is unable to read French.) There is precedent for it: RFC 4357 has normative references to documents only in Russian.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Fri, 20 Feb 2015 14:01:40 -0500

> undergoing maintenance" so I will search a reference later.

Not sure if this would be a useful reference, but:
http://hedgehog.dns.icann.org/hedgehog/hedgehog.html

Claims more lik 40kqps, and ~27kqps of NXD.

W

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