[dns-privacy] Stephen Farrell's Yes on draft-ietf-dprive-problem-statement-05: (with COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-dprive-problem-statement-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-problem-statement/



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