On Dec 1, 2013, at 12:09 PM, Stephane Bortzmeyer <bortzme...@nic.fr> wrote:

> On Wed, Nov 27, 2013 at 09:42:16AM -0800,
> Paul Hoffman <paul.hoff...@vpnc.org> 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?

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.

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

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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to