Subject: Re: [DNSOP] DNS privacy draft

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 1 Dec 2013 21:09:31 +0100

On Wed, Nov 27, 2013 at 09:42:16AM -0800,
 Paul Hoffman <[email-masked]> wrote 
 a message of 52 lines which said:

> 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. :-)

Let me rephrase it to be sure I've understood: I should split the
draft in two, one draft only exposing the privacy issues and another
one (or several?) describing the proposed solutions. Correct? If so,
what is the opinion of the rest of this working group?

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

Please go ahead, you can discuss any part of the draft you want.

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

Send text :-) I suggest not to do this myself but to point to the
various studies using the DNS traffic to find out what the people are
doing. Would it address your request?

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 1 Dec 2013 13:06:06 -0800

On Dec 1, 2013, at 12:09 PM, Stephane Bortzmeyer <[email-masked]> wrote:

> one (or several?) describing the proposed solutions. Correct?

Or retitle the draft from "DNS privacy problem statement" to "List of Solutions for DNS Privacy". When I started reading, I assumed that this was really a problem statement. That was further emphasized by the lead-in to Section 5 that says "Remember that the focus of this document is on describing the threats, not in detailing solutions." 

> If so,

This still feels like a misuse of the DNSOP WG. The beginning of Section 5.1.2 declares (I believe correctly) "To really defeat an eavesdropper, there is only one solution: encryption." The section then goes on to show why that is not possible with today's protocols. Thus, this seems exactly wrong for the DNSOP WG. I strongly propose that this type of DNS work be done in the Applications Area because it is those applications that need to be analyzed and likely changed to fit the scenarios you describe.

> Please go ahead, you can discuss any part of the draft you want.

Here's a start: "Padding the DNS query stream will have a negative effect on the DNS systems as a whole, but will only thwart passive surveillance for those attackers who cannot store and process the larger stream. There is no current evidence that the bad actors in question have such limitations."

> Send text :-)

It's not just added text, and nor does it have a smiley. It is a completely different view than what you have in the current document.

> I suggest not to do this myself but to point to the

Not really, because almost no one reading this document will actually read the studies. It would be better if the draft itself described what we know about how users' applications tend to do DNS requests for the users and not make any implication that the user understands this.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 1 Dec 2013 16:20:29 -0500

> Here's a start: "Padding the DNS query stream will have a negative effect on the DNS systems as a whole, but will only thwart passive surveillance for those attackers who cannot store and process t…

I thought the point of padding was to prevent the attacker from using the length of the encrypted query or response to make correlations and guess the plaintext.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 1 Dec 2013 13:44:50 -0800

> I thought the point of padding was to prevent the attacker from using the length of the encrypted query or response to make correlations and guess the plaintext.

That's not how Stephane has it defined in the draft in question:

   padding (sending random queries from time to time)

   For instance, padding, sending
   gratuitous queries from time to time (queries where you're not
   interested in the replies, just to disturb the analysis), is useful
   against all sorts of observers.  It is a costly technique, because it
   increases the traffic on the network but it seriously blurs the
   picture for the observer.

Maybe a different word would be useful, but I still think that the proposal is silly unless we believe that the attacker cannot determine which are real queries and which are not.

--Paul Hoffman

---

From: "Niall O'Reilly" <[email-masked]>
Date: Sun, 1 Dec 2013 23:31:26 +0000

> On 1 Dec 2013, at 21:44, Paul Hoffman <[email-masked]> wrote:
> 

a better word might be "chaff"

---

From: joel jaeggli <[email-masked]>
Date: Sun, 01 Dec 2013 19:41:26 -0800

On 12/1/13, 1:06 PM, Paul Hoffman wrote:
>> On Wed, Nov 27, 2013 at 09:42:16AM -0800, Paul Hoffman
>> <[email-masked]> wrote a message of 52 lines which said:
>> 
>>> implications, and not the suggested changes to deal with them.
>>> Choose a story and stick to it. :-)
>> 
>> draft in two, one draft only exposing the privacy issues and
>> another one (or several?) describing the proposed solutions.
>> Correct?
> 
> Or retitle the draft from "DNS privacy problem statement" to "List of
> Solutions for DNS Privacy". When I started reading, I assumed that
> this was really a problem statement. That was further emphasized by
> the lead-in to Section 5 that says "Remember that the focus of this
> document is on describing the threats, not in detailing solutions."
> 
>> If so, what is the opinion of the rest of this working group?
> 
> This still feels like a misuse of the DNSOP WG. The beginning of
> Section 5.1.2 declares (I believe correctly) "To really defeat an
> eavesdropper, there is only one solution: encryption." The section
> then goes on to show why that is not possible with today's protocols.
> Thus, this seems exactly wrong for the DNSOP WG. I strongly propose
> that this type of DNS work be done in the Applications Area because
> it is those applications that need to be analyzed and likely changed
> to fit the scenarios you describe.

I see that as an operational problem. Protocol changes are probably not
something we should do here by if you need to talk about the problem
from the vantage point of a consumer or an operator that seems ok.

>>> We haven't gotten into commenting on the stuff in section 5. When
>>> we do, I'll point out the futility of gratuitous queries.
>> 
> Here's a start: "Padding the DNS query stream will have a negative
> effect on the DNS systems as a whole, but will only thwart passive
> surveillance for those attackers who cannot store and process the
> larger stream. There is no current evidence that the bad actors in
> question have such limitations."
> 
>> 
>>> "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.
>> 
>> Send text :-)
> 
> It's not just added text, and nor does it have a smiley. It is a
> completely different view than what you have in the current
> document.
> 
>> I suggest not to do this myself but to point to the various studies
>> using the DNS traffic to find out what the people are doing. Would
>> it address your request?
> 
> Not really, because almost no one reading this document will actually
> read the studies. It would be better if the draft itself described
> what we know about how users' applications tend to do DNS requests
> for the users and not make any implication that the user understands
> this.
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 2 Dec 2013 08:57:50 +0100

On Sun, Dec 01, 2013 at 11:31:26PM +0000,
 Niall O'Reilly <[email-masked]> wrote 

> a better word might be "chaff"

OK. And do note "chaff" may be a by-product of
draft-wkumari-dnsop-hammer.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 2 Dec 2013 13:13:26 -0500

> draft-wkumari-dnsop-hammer.

Um, please explain.

Hammer (and the various similar, actually implemented things) simply trigger lookups a few seconds before the TTL would naturally expire *in response to an incoming query*.
The additional number of queries is small (a bit less than lowering your TTL by HAMMER_TIME).

W

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

--
Credo quia absurdum est.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Dec 2013 23:02:34 +0100

On Thu, Nov 28, 2013 at 11:10:39AM -0500,
 Paul Wouters <[email-masked]> wrote 
 a message of 58 lines which said:

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

It seems to me, not an argument against encryption, but an argument
against relying on encryption alone. When facing pervasive monitoring,
there is little chance we'll find _one_ solution that will solve
everything. We need a set of solutions. To address the problem you
mention, the solution is QNAME minimization, described in
draft-bortzmeyer-dnsop-dns-privacy.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Dec 2013 23:20:16 +0100

On Mon, Dec 02, 2013 at 01:13:26PM -0500,
 Warren Kumari <[email-masked]> wrote 
 a message of 35 lines which said:

> Hammer (and the various similar, actually implemented things) simply
> trigger lookups a few seconds before the TTL would naturally expire
> *in response to an incoming query*.

OK, I was too fast, sorry. Hammer itself does not scramble the stream
of requests. So, I withdraw the reference to Hammer.

Still, sending gratuitous queries, without an incoming query and
without waiting for the expiration, may be a good strategy for a
resolver to make traffic analysis more difficult for the eavesdropper
(or for the authoritative name servers).

---

From: Warren Kumari <[email-masked]>
Date: Tue, 3 Dec 2013 21:24:27 -0500

> of requests. So, I withdraw the reference to Hammer.

Okey dokey (and the hackles go down :-P)

--
The plural of anecdote is not evidence.
        -- Bill Lockyer, California Attorney General

---

From: "Wiley, Glen" <[email-masked]>
Date: Tue, 10 Dec 2013 13:33:07 +0000

>(or for the authoritative name servers).

I have read and support this draft with a few exceptions:

Large scale authoritative name servers (such as our COM/NET footprint)
already sort through an enormous stream of query data so while the chaff
might sound nifty I can't imagine it having a meaningful effect on the
ability for authoritative servers to analyze traffic until it reaches DOS
volumes.  Even for smaller operators this will certainly force changes to
infrastructure but I question whether it will result in reduced ability to
perform traffic analysis.

The other concern that I have is the idea of recursive resolvers holding
long lived sessions open with the authoritative servers.  This bears
closer analysis but my experience with COM/NET makes me nervous about that
idea.  I'd like to hear how other authoritative name server operators feel
about the implications of long lived TCP connections on their name servers.