[dns-privacy] Warren Kumari's Discuss on draft-ietf-dprive-rfc7626-bis-06: (with DISCUSS and COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-dprive-rfc7626-bis-06: Discuss

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-rfc7626-bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Apologies for changing my YES to a DISCUSS -- I found a later version of my
notes on this draft.

My DISCUS is specifically around the"The Alleged Public Nature of DNS Data" /
"It has long been claimed that "the data in the DNS is public" section -- it
seems to be unnecessarily creating and then shooting down a strawman. The "the
data in the DNS is public" aphorism talks is more about the confidentiality one
can expect **publishing** data in the DNS, not the privacy of the lookups. 
This whole section (to my mind) undersells the threat that publishing something
in the DNS and expecting it to remain private creates -- for example, I'd be
extremely foolish to insert: my-password-fd345432233e.example.com 600 IN TXT
"Hunter2"

Services like Farsight Securities (excellent!) DNSDB will likely capture this
almost as soon as I use it somewhere. In addition, the "Due to the lack of
search capabilities, only a given QNAME will reveal the resource records
associated with that name" sentence is either false, or at the very least,
misleading.

$ dig +dnssec foo.ietf.org | grep NSEC
clearly tells me that the names etherpad.ietf.org and ftp.ietf.org both exist,
and $ dig +dnssec ftpa.ietf.org | grep NSEC tells me that the next name is
guides.ietf.org....

I think that the last 4 or 5 sentences of the section are useful, but that the
rest of the section is actively dangerous as it is likely to be misunderstood.

Please don't misunderstand - I still believe that the document itself is really
important and useful, but the section seems dangerous (and yes, I realize that
it is in RFC7626)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[Edit: I accidentally hit "Send" too early; I have another few comments, also
non-blocking: 1: "Also, sometimes, the QNAME embeds the software one uses,
which could be a privacy issue. For instance,
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org."... Unless you
are a Microsoft or DNS weenie, this is likely not at clear -- what is being
leaked here? The fact that the site uses TCP? LDAP? Windows? Goldbach's
Conjecture? Example software? (I think adding a sentence here would be
helpful...) ]

Thank you for this document - it's really useful, and readable as well.

I do have a few small comments to (possibly) make it even better - I will in no
way be offended if you ignore these...

The background on how DNS works is nicely written, and I'm to point people at
it when I need to explain how the DNS works -- but I think a better name
example than: "What are the SRV records of _xmpp-server._tcp.example.com?"
would be good -- SRV is an unusual record type, and names with underscores
surprise people. I'd instead suggest "What is the MX records for example.com"
or "What is the A record for ftp.example.com?" -- I'm only mentioning this
because the rest of the section is a very general introduction and this might
confuse newcomers...

"At the time of writing, almost all this DNS traffic is currently sent in clear
(i.e., unencrypted). However there is increasing deployment of DNS-over-TLS
(DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], particularly in mobile
devices, browsers, and by providers of anycast recursive DNS resolution
services." I think that you might want to remove the "particularly in ..." - I
suspect that it will not age well; the document does say "At the time of
writing" and "increasing", etc., but this document is likely foundational
enough that it will still be referenced many many years from now, and this text
may just cloud matters then.

Whatever the case, thanks again for this document!