DNS Privacy Considerations
draft-ietf-dprive-problem-statement-06

[Ballot comment]
Thanks for doing this work.

You might want to include a reference to ENUM in Section 2.2.

I wonder if it's worth mentioning traffic analysis somewhere in the document (or if it's mentioned in one of the references I didn't have time to scan?). Even for an observer who does not have access to the content of DNS requests/responses, I would imagine it's possible to glean some information about what the user is doing based solely on the metadata associated with the DNS traffic (e.g., identifying when a host is likely making a particular type of request or a specific sequence of requests).

In Section 4, I would caution against saying there is no court precedent unless you know for sure that there is not. My guess would be that DNS traffic logs have probably been entered into evidence in some court somewhere in the world for some purpose, so there may well be some precedent about something even if we don't know what it is or how broadly it applies.

[Ballot comment]
Only positive comments here, because they're important too:

As the document shepherd says: "While problem statement documents are often viewed as a waste of time, this particular one has been very useful, to help get everyone on the same page."  Indeed, and thanks for doing this.

This document probably has the highest reference count per document page that I've seen.  That said, I find the reference list to be well chosen and helpful, and the separation of the few normative references to be just right.  Thanks for that, as well.

[Ballot comment]
As an editorial/organizational nit, I would probably consign the actual description of the dns protocol in the introduction ( paragraph 3/4) to a subsection so that it can be distinct from the other introductory text preceding it and the introductory analysis that follow.

[Ballot comment]

Very good stuff, thanks for the work and I can't wait to
see our eventual mitigation solutions get tested and
deployed.

- p4, primary request: "of interest to the eavesdropper" isn't
quite right - the eavesdropper is probably more interested in
the URL and not just the DNS name from the URL.

- p4, "glue records" - you didn't say what those are

- p4, "it is a big privacy concern" is unclear - do you mean
autocomplete? Or (as implied by the next sentence) do you mean
pre-fetching the names in href's? Better to be clearer.

- 2.1 - the "alleged" in the title isn't really needed but may
be ok to leave in for emphasis. Maybe a better section title
would be "DNS data is public, DNS transactions ought not be
public" or similar

- 2.2: the [denis-edns-client-subnet] reference doesn't point
at a great URL for an RFC, be great if there were a better
reference. The same issue may come up wrt some of the other
references. I think in this case, it should be fine to leave
those as-is if there aren't easily found better sources as this
is not a protocol specification and so the RFC editor will not
(I hope) be as worried about the stability of these.

- 2.4: Be better to expand IAP on 1st use

- 2.5.2 (or elsewhere): a lot of the traffic that arrives at
TLD authoritative servers is due to errors, as noted. However,
those errors (when due to typing) are also possibly privacy
sensitive, e.g. perhaps one for alcolicsanonymous.com. I don't
think that issue is noted, and it probably ought be somewhere.
(Maybe not here, as it is relevant to all DNS servers.)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dprive-problem-statement-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DNS privacy considerations) to Informational RFC


The IESG has received a request from the DNS PRIVate Exchange WG (dprive)
to consider the following document:
- 'DNS privacy considerations'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-05-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the privacy issues associated with the use of
  the DNS by Internet users.  It is intended to be an analysis of the
  present situation and does not prescribe solutions.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dprive-problem-statement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dprive-problem-statement/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) Informational.


(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

This document describes the privacy issues associated with the use of
the DNS by Internet users. It is an attempt at a comprehensive and accurate
list, but does not prescribe solutions.

Working Group Summary:

There was no controversy or serious disagreement.
The document went through the WG smoothly, and with agreement that it
is useful.

Document Quality:
The document describes the privacy implications of sending DNS queries
in the clear. It provides some introductory information, discusses the
risks, and dispels some myths. While problem statement documents are
often viewed as a waste of time, this particular one has been very
useful, to help get everyone on the same page.


Personnel:

Warren Kumari will be the document shepherd, Brian Haberman is the AD.

(3) The Document Shepherd has read, provided feedback and followed the document though its life cycle, and believes it is ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
Nope.

(5) Do portions of the document need review from a particular or from broader perspective.
Nope.

(6) Describe any specific concerns or issues that the Document Shepherd has.
None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required.
Yes.

(8) Has an IPR disclosure been filed that references this document?
Nope.

(9) How solid is the WG consensus behind this document?
Strong consensus, with good participation.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
Nope. Motherhood and apple pie.

(11) Identify any ID nits the Document Shepherd has found in this document.
None - the nit checker says: Looks like a reference, but probably isn't: '1' on line 720
It *is* a reference, perhaps it could be clarified - a job for the RFC Editor.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
None.

(13) Have all references within this document been identified as either normative or informative?
Yes. There are many, mostly informative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
None.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
No.


(16) Will publication of this document change the status of any existing RFCs?
No.

(17) Describe the Document Shepherd's review of the IANA considerations section:
" This document has no actions for IANA. ". I checked that many times.
It is correct, and spelt correctly as well. It's even in a pretty font (Sorry, this joke never gets old... well to me at least...)


(18) List any new IANA registries that require Expert Review for future allocations.
None.

(19) Describe reviews and automated checks performed by the Document Shepherd
None needed.

Administrivia - forgot to update the datatracker when we called consensus. Stephane is integrating last few TODO's, will post when window opens, then will post DS