Recommendations for DNS Privacy Service Operators
draft-ietf-dprive-bcp-op-14

I found this document to be interesting, useful, and well written.  Thank you for your work in this area.

Regards,
Rob

** Per 6.1.1.  Item 2.  Per “Data Collection and sharing … and in each case whether it is aggregated, pseudonymized, or anonymized and the conditions of data transfer”, would be useful to also have the policy describe the technique used to realize this minimization?

** Section 6.1.2.  Item 5.  Per “Jurisdiction.  This section should communicate the applicable jurisdictions and law enforcement regimes …”, what’s a “law enforcement regime” (and why is that different than a “jurisdiction”)?

** Section 6.2.1.  Per item 5.4.  Why restrict disclosure to “law enforcement agencies, or other public and private parties dealing with security and intelligence”, and not request disclosure of all parties who get access with “Specify whether the operator has any agreement in place with public or private parties to give them access to the server and/or to the data”?  One party’s assessment of an entity as “security” (captured in the current text) is another’s “public safety” (not captured in the current text but captured the recommend text)

** Editorial Nits
-- Section 6.1.2.  Typo. s/section Section 5/Section 5/g

-- Section 6.1.2  Editorial Nit. Per item 5.2, “… and how to contact the operator to enforce them”, it is more appropriate to say “exercise them”, e.g., a user contacts the operator to exercise their “right to be forgotten” (not enforce their right to be forgotten).

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.

I think this is a very useful document and I am looking forward to it getting published.

I support updated Ben’s DISCUSS.

**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                   *
* Recipients of these reviews are encouraged to reply to me directly * 
* about perceived successes or failures of this experiment.          *
**********************************************************************

The following comments were provided by Benjamin Schwartz <bemasc@google.com>:

Benjamin would have balloted *DISCUSS* on this document. He wrote:

This draft is close to ready, but it contains some elements that are not appropriate for IETF publication or lack IETF consensus.

## Section 1

Typo: “For example the user has a clear expectation of which resolvers have visibility of their query data however this...” -> Add a period before “however”.

Inappropriate subject matter:

    It is an untested area that simply using a DNS
    resolution service constitutes consent from the user for the operator
    to process their query data.

This is legal speculation, not appropriate for IETF.  Strike this sentence.

Clarity:

    Privacy considerations specifically
    from the perspective of an end user ... are out of scope.

This seems confusing as written: surely it is the privacy of end users (and not of resolver operators) that this draft seeks to protect.  Please rephrase or omit this disclaimer.

## Section 5.1

Version skew: dprive-rfc7626-bis no longer has a Section 2.4.2 or 2.5.3.

## Section 5.1.2

Clarity: Redirection of traffic to rogue servers does not match the usual definition of “surveillance”.  I would suggest adding an explanation of how this active attack is a privacy threat.  Presumably you are referring to merely intercepting the user’s DNS queries, as opposed to substituting modified DNS responses in order to monitor post-DNS network activity, but the text is not clear on this distinction.

## Section 5.1.3.1

Current practices:  I don’t think either EDNS(0) Keepalive or DNS Stateful Operations is currently in use with DNS-over-TLS, so this recommendation seems too strong for a BCP.  For example, this could say “Management of TLS connections as described in RFC 7766.  EDNS(0) Keepalive and DNS Stateful Operations may provide additional performance benefits.”

Scope: The optimizations here are performance optimizations, which seem out of place in this document.  I would suggest focusing the document on “Encrypted DNS Service Privacy Recommendations”, and remove any recommendations related to performance and reliability, which are already well-covered by standards-track RFCs.

## Section 5.2.1

Content: I think there’s a missing mitigation here, which is employed virtually universally among large DNS Privacy deployments: IP erasure.  DNS operators typically distinguish between PII-logs, which are retained at most briefly, and non-PII logs, which are retained for a longer period.  I believe this is a best practice and worth documenting.


## Section 5.3.1

Document interaction: This section comes awfully close to updating or deprecating ECS, which we do not have IETF consensus for.  I think the BCP here should restrict itself to disclosing the server’s ECS behavior and imposed prefix length limit.

## Section 6.1.1

Terminology: “PII” appears here for the first time, and is not defined.

Thanks for addressing my DISCUSS and COMMENT.

I support Ben's DISCUSS.

I support Ben’s DISCUSS.

Other comments:

Throughout, “privacy-related” needs the hyphen, as it’s a compound modifier.

— Section 1 —

   For example the user has a clear expectation of which
   resolvers have visibility of their query data however this resolver/
   transport selection may provide an added mechanism to track them as
   they move across network environments.

This sentence needs some punctuation: certainty, a comma after “for example”, and probably one before “however”.  Even with those, it’s an awkward sentence and you might consider rephrasing it.

   It is an untested area that simply using a DNS
   resolution service constitutes consent from the user for the operator
   to process their query data.

NEW
   Whether simply using a DNS resolution service constitutes consent
   from the user for the operator to process their query data is as yet
   untested.
END

   o  To introduce the DNS Recursive Operator Privacy (DROP) statement
      and present a framework to assist writers of this document.

When I read this, I thought you meant *this* document, and that didn’t make sense.  You mean “that document”, or, better, “writers of a DROP statement.”

      DROP statement is a document that an operator can publish
      outlining their operational practices and commitments with regard
      to privacy thereby providing a means for clients to evaluate the
      privacy properties of a given DNS privacy service.

This needs at least a comma before “thereby”.  I might also change to “publish, which outlines ... privacy, and thereby provides a means”.

(At this point I’m going to stop calling out all but the most hard-to-follow editorial issues.)

— Section 2 —

   Whilst the issues raised here are targeted at those operators who
   choose to offer a DNS privacy service, considerations for areas 2 and
   3 could equally apply to operators who only offer DNS over
   unencrypted transports but who would like to align with privacy best
   practice.

If we’re considering encryption to be part of the best practice, this seems odd.  Maybe say “but who would otherwise like to align...”?

— Section 5.1.1 —

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

There’s no reason to hyphenate the former, and the latter should also be expanded here:

NEW
   o  DNS over TLS [RFC7858] and [RFC8310].
   o  DNS over HTTPS [RFC8484].
END

Similarly, take the hyphens out of “DNS over DTLS” in the next paragraph, and out of “DNS over TLS” throughout the document.

— Section 5.1.3.2 —
It’s “forgo” (give up), not “forego” (go before).

— Section 8 —
For a document such as this, the Security Considerations sectiin seems very meagre.  As the Sec ADs have not called this out, I’ll presume they think it’s OK, and I won’t press the issue.  Perhaps all relevant information is already elsewhere in the document.

Thanks for addressing my final batch of comments.

Thanks for addressing my comments - it reads much better.

A couple of small comments/questions:

1) RFC2119/RFC8174 disclaimer is present in section 4, however, it does seem to be the case that normative language is used. I would recommend to actually use normative language in this doc!

2) Can you actually provide references for the techniques listed in Table 1?

3) Sec 5.1.3.1:
“A DNS-over-TLS privacy service on both port 853 and 443.  This
      practice may not be possible if e.g. the operator deploys DoH on
      the same IP address.”
Isn’t 443 basically DoH? Why would you deploy DoT over 853? Is that a common practice? Sorry if I miss something...

4) As a side node to the AD and shepherd: Answer to question 7 in shepherd write-up is “(7) No IPR Disclosures” which does not really answer the question if all author have confirmed that they are not aware of any additional IPR they would need to disclose…

* Section 5.2.3.

I found Table 1 to be extremely confusing. It is not clear from the table whether all of the properties are concurrently applicable to a certain technique when an "X" appears there. e.g. TC has marks for Format preserving, Prefix preserving, Reordering/Shuffling, and Random substitution. Some of these seem to be mutually exclusive. It would be good if you can clarify. 

I support Alissa and Ben's Discusses.