[dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Adam Roach via Datatracker <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-dprive-bcp-op-08: No Objection

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-bcp-op/



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

Thanks to the document authors, as well as everyone else who
contributed to this document for all the work that went into
its creation.  I have a handful of editorial suggestions that
you may wish to take into account prior to publication. (I also
have one request and one question in the list below.)

I also support the first point of Alissa's discuss, and have
elided several comments about Section 5.1.7 from my review
below with the expectation that it will be removed.

---------------------------------------------------------------------------

§1:

>  Community insight [or judgment?] about operational practices can
>  change quickly, and experience shows that a Best Current Practice
>  (BCP) document about privacy and security is a point-in-time
>  statement.  Readers are advised to seek out any errata or updates
>  that apply to this document.

RFC Errata are intended only to correct documents to reflect what
the community believed they should have said at the time of publication
(e.g., typographic errors, omissions in state machines), and not to
provide updates to reflect later thinking. Please remove "errata or"
from this sentence.

---------------------------------------------------------------------------

§5.1.1:

>  o  DNS-over-TLS [RFC7858] and [RFC8310].
>
>  o  DoH [RFC8484].

Nit: For the sake of consistency, I would recommend either contracting
both of these (e.g., "DoT" and "DoH"), or expanding them both.

This same comment applies to the prose in section 5.1.2, as well
as the titles of 5.1.3.1 and 5.1.3.2.

---------------------------------------------------------------------------

§5.1.2.1:

>  o  Mis-identification of a server by a client e.g. typos in URLs or
>     authentication domain names [RFC8310].

It's a bit unclear which kind of URLs this is referring to. Based on the
proposed mitigation, I suspect it's talking about the use of URLs to
configure a DNS server? Consider clarifying the URL's purpose in this
text.

---------------------------------------------------------------------------

§5.1.3.2:

The use of EDNS(0) padding is conspicuous by its absence from this
section. Is this intentional?

---------------------------------------------------------------------------

§5.1.4:

>  DNS Privacy Threats:
>
>  o  Users may be directed to bogus IP addresses for e.g. websites
>     where they might reveal personal information to attackers.

You might want to consider a different example than websites here. 80% of
worldwide website traffic is secured by HTTPS, which means than any such
attempts will be prevented by WebPKI certificate mismatches.

Notably, this means that the mitigation proposed is of diminished value
for DNS servers that are used primarily or exclusively for resolving
web server addresses, and the calculus of whether the overhead of
implementing DNSSEC in such servers is worth the value it provides may
vary radically from that which applies to general-purpose name resolvers.
Given the fairly absolute language in the current mitigation section
(only three mitigations use something as strong as "must"), it is
probably worthwhile adding some text that acknowledges that the value
of this mitigation varies depending on the applications that use the
DNS service.

---------------------------------------------------------------------------

§6.1.1:

>  4.  Associated entities.  Declare any partners, third-party
>      affiliations, or sources of funding.

Having looked at a number of such disclosures recently, I've noticed
that it has become fashionable to make such disclosures in the form
of "<Corporation> may share information about our customers among
the <corporation> family of companies," while eliding information
that, for example, one such company is a user-tracking-based
advertising network.

So, if we're making suggestions for ideal policies, I might suggest
something a bit more explicit, like:

   4.  Associated entities.  Declare and explicitly enumerate any
       partners, third-party affiliations, or sources of funding.

---------------------------------------------------------------------------

§B.2:

>  Since 2006, PowerDNS have included a de-identification tool
>  Appendix B.2 with their PowerDNS product.

There appears to be a spurious "Appendix B.2" on the second line of
this paragraph.