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

[Ballot comment]
[ section 5.1.1 ]

* "encryption of DNS traffic can protect against active injection" ->
  "...active injection on the paths traversed by the encrypted connection"?

  This is discussed in 5.1.4, but if you don't want to make the reader wait
  that long the above edit might suffice.

[ section 5.2.5 ]

* Are none of the recommendations in ISC-Knowledge-database-on-cache-snooping
  worth including here, even if quoted verbatim?

[ section B.2.3 ]

* "TCPdrpiv" -> "TCPdpriv"

[Ballot comment]
I suggest getting rid of use of BCP 14 entirely.  There are only two SHOULDs in the whole thing, and I don't think you need them.

I also suggest reviewing Barry's editorial comments, because I observed the same issues for things like "DNS-over-DTLS" and "DNS-over-TLS", for example.

[Ballot comment]
I suggest getting rid of BCP 14 entirely.  There are only two SHOULDs in the whole thing, and I don't think you need them.

I also suggest reviewing Barry's editorial comments, because I observed the same issues for things like "DNS-over-DTLS" and "DNS-over-TLS".

[Ballot discuss]
Trimmed to the one outstanding point from my original DISCUSS:

I do not think item #5 in Section 6.1.2 belongs in this document. I don't see how it is within scope for the IETF to be specifying these sorts of best practices, which are not technical or operational in nature but focus on legal matters and likely require the involvement of lots of lawyers in order to get the provisions written. This section implies that the DROP documents would become legal/compliance documents by nature, which may or may not be a good choice but is not within the remit of the IETF to specify. Also, I think what this section asks for is not the norm today and therefore it seems odd for the IETF to specify a best practice that operators may not have any chance of being able to comply with (e.g., listing specific law enforcement agencies, privacy laws, or countries where data centers will reside and the data will never move from them).

[Ballot comment]
Thank you for the updates,  including those that resolve my Discuss points.
I do have several new comments on the -10.

[note that I did not attempt to repeat comments made at
https://mailarchive.ietf.org/arch/msg/dns-privacy/bOK3mcSn-79wrAsawRQONBOZGGI/ ]

Section 1

  Whilst protocols that encrypt DNS messages on the wire provide
  protection against certain attacks, the resolver operator still has
  (in principle) full visibility of the query data and transport
  identifiers for each user.  Therefore, a trust relationship exists.

I commented previously about the strained nature of this conclusion, and
part of the response to that comment included a statement that "this
text is from the original RFC 7626".  However, I don't see any sign of
this statement in RFC 7626 (and, per google, any other RFC), so perhaps
the reluctance to update at this stage is misplaced.

Section 5.1.3.2

Is (HTTP/2, EDNS(0)) padding a privacy threat or a mitigation?

Section 5.2.1

  The following are recommendations relating to common activities for
  DNS service operators and in all cases such activities should be
  minimized or completely avoided if possible for DNS privacy services.

Are the "such activities" that should be avoided the "common activities"
that we're giving recommendations for?

Section 5.2.4

nit: comma before "e.g." (as well as after)

Section 5.3.1

  operator is happy with.  However some operators consider allowlisting
  to incur significant operational overhead compared to dynamic
  detection of ECS on authoritative servers.

nit(?): is this "detection of ECS support"?

Section 6.1.2

Should we mention the DoH URI template (if any) here, as well as the
address+port combos, DoT authentication domain name/SPKI/etc.?

  2.  Client facing capabilities.  With reference to Section 5 provide
      specific details of which capabilities are provided on which
      client facing addresses and ports:

Is perhaps Section 5.1 a better reference than all of Section 5 here?

Section 8

We should probably link to the security considerations sections of
DoT+DoH as well as RFC 7766.  Arguably, those for DNSSEC as well.

Section 12.1

It's not immediately clear that RFC 8404 needs to be a normative
reference (it's cited for the DNS Privacy Threat that "increased use of
encryption can impact [...] operator ability to monitor traffic" but
that's just an informative notice and does not really give specific
implementation advice to adhere to.

Section 12.2

The way in which we cite RFC 7457 seems to be incorporating it by
reference, which would arguably make it a normative reference.

RFC 7706 should also be normative, since we have a recommended behavior
for running root on loopback.

Likewise we mandate/recommend behavior from RFCs 7871, 8020, 8198, and
8490, making them normative.

Appendix A.2

  o  Section 8 of [RFC8484] outlines the privacy considerations of DoH.
      Note that depending on the specifics of a DoH implementation there
      may be increased identification and tracking compared to other DNS
      transports.

I would suggest noting that this document recommends against the use of
these mechanisms that might lead to increased identification/tracking.

Appendix B

nit: s/Pseudoanonymization/Pseudonymization/

  use of a format-preserving technique is essential.  This, though, is
  not cost-free - several authors (e.g., [Brenker-and-Arnes] have
  observed that, as the entropy in an IPv4 address is limited, given a
  de-identified log from a target, if an attacker is capable of
  ensuring packets are captured by the target and the attacker can send
  forged traffic with arbitrary source and destination addresses to
  that target, any format-preserving pseudonymization is vulnerable to
  an attack along the lines of a cryptographic chosen plaintext attack.

nit(?): the way this is written ("given a de-identified log from a
target") makes it sound like the log is obtained first, and then
afterward (new) traffic with known addresses is generated (i.e., not in
the initial log), and somehow this allows for the deanonymization.  My
understanding was that the known traffic needed to be part of the log
being deanonymized, i.e., the causality reversed from my above
description.

Appendix B.1

  o  Filtering.  Removing (and thus truncating) or replacing data in a
      field.  Field data can be overwritten, often with zeros, either
      partially (grey marking) or completely (black marking).

Is there a reference for grey/black marking?  If they are not in common
use, perhaps there is not additional value from mentioning these names.

Section D.1

There may be some privacy relevance to the precision of timestamp used
for the various (logging) operations, relating to (e.g.) recorrelation
with external datasets.

[Ballot discuss]
I have added more detail to point #3 below as requested on today's telechat.

(1) Picking up on a Gen-ART review comment: Section 5.1.7 seems to be aimed at entities other than the operators of DNS privacy services. That is, the "impact" seems like it is on third-party entities, but then the "optimization" talks about DNS privacy service operators using "alternative means for traffic monitoring." I guess what I don't understand is why the DNS privacy service operators need alternative means, since they still have access to the cleartext.

(2) I think Section 6 needs to clarify that it is providing suggestions only on matters relating to the technical operation of DNS privacy services that may be described in DROP policies, and not on any other matters. There are numerous other matters that are typically addressed in privacy statements (e.g., what form of legal process the operator requires to supply data to law enforcement, how the operator handles data about children, etc.). This document should not give the impression that the listed items in the subsections are an exhaustive list, nor should it attempt to offer an exhaustive list.

(3) I do not think item #5 in Section 6.1.2 belongs in this document. I don't see how it is within scope for the IETF to be specifying these sorts of best practices, which are not technical or operational in nature but focus on legal matters and likely require the involvement of lots of lawyers in order to get the provisions written. This section implies that the DROP documents would become legal/compliance documents by nature, which may or may not be a good choice but is not within the remit of the IETF to specify. Also, I think what this section asks for is not the norm today and therefore it seems odd for the IETF to specify a best practice that operators may not have any chance of being able to comply with (e.g., listing specific law enforcement agencies, privacy laws, or countries where data centers will reside and the data will never move from them).

[Ballot comment]
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 :

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.

[Ballot comment]
* 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.

[Ballot 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 " may share information about our customers among
the  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.

[Ballot discuss]
[updated to add one discuss point and a comment section]

This document is trying to make normative references to sections of
draft-ietf-dprive-rfc7626-bis that have not existed since the -00 of that
document, with the content having been removed for being too controversial.
Do we need to delay processing this document until 7626bis has settled down
and it is clear what content we can refer to in that vs. needing to incorporate
into this document?  (It's unclear that such content would be less controversial
in this document than in that one.)
Specifically, Section 5.1.2 of this document refers to Section 2.5.3 of that document
("Rogue Servers").

[new discuss point]

This is perhaps more a flaw in RFC 8310 than in this document, but I'd still
like to discuss it: in Section 5.1.2 we read that:

  When using DNS-over-TLS clients that select a 'Strict Privacy' usage
  profile [RFC8310] (to mitigate the threat of active attack on the
  client) require the ability to authenticate the DNS server.  To
  enable this, DNS privacy services that offer DNS-over-TLS should
  provide credentials in the form of either X.509 certificates
  [RFC5280] or Subject Public Key Info (SPKI) pin sets [RFC8310].

Authenticating the DoT server via X.509 certificate as described here and in
RFC 8310 seesm to involve looking for an ADN in the certificate; however, I
could not find any discussion of how to know what CA(s) or trust anchors to
trust to certify the ADN in a certificate.  It's possible that RFC 8310's
use of "PKIX Certificate" is supposed to imply that Web PKI trust anchors
are used, but that's not immediately clear.  It may be the case that we need
to mention provisioning a trust anchor as well as the X.509 certificate
information, here.

[Ballot comment]
The organizational structure of (the subsections of) Section 5 is pretty
confusing to me -- though we talk about having the two classes of threats
and the three classes of actions, those are used mostly for structure within
a given section, and the ordering and headings of the (sub)sections
themselves seem somewhat arbitrary.  We don't seem to try to align with the
organization of RFC 6973 or some other structure, so this ends up coming
across to me as something of a jumbled list of scenarios and
recommendations.  I guess I'm not quite the target audience, though, so salt
as needed.

In general it's better to reference RFC 7525 as BCP 195 than just the RFC
number.

Section 1

  In recent years there has also been an increase in the availability
  of "public resolvers" [RFC8499] which users may prefer to use instead
  of the default network resolver because they offer a specific feature
  (e.g. good reachability, encrypted transport, strong privacy policy,
  filtering (or lack of), etc.).  These open resolvers have tended to
  be at the forefront of adoption of privacy related enhancements but
  it is anticipated that operators of other resolver services will
  follow.

I'm wary of suggesting changes at this late stage, but it seems to me that
users may also prefer a public resolver when there is not good information
available about the local network-provided resolver.  In some sense this is
not exactly a "feature" of the public resolver but rather an "anti-feature"
of the alternative.

  Whilst protocols that encrypt DNS messages on the wire provide
  protection against certain attacks, the resolver operator still has
  (in principle) full visibility of the query data and transport
  identifiers for each user.  Therefore, a trust relationship exists.

(side note; this should have been a WGLC comment but is probably too late to
make now: this conclusion seems a bit strained, and I might say instead "a
trust relationship (whether explicit or implicit) is assumed to exist
between each user and the operator of the resolver(s) used by that user".)

  It should also be noted that the choice of a user to configure a
  single resolver (or a fixed set of resolvers) and an encrypted
  transport to use in all network environments has both advantages and
  disadvantages.  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.  Commitments from operators to

nits: comma after "For example" and some punctuation before and after
"however".

  minimize such tracking are also likely to play a role in user
  selection of resolvers.

I'm not entirely sure what this is intended to convey.  If a user is to use
a fixed resolver for *all* their network environments, wouldn't the user
need such a commitment from *all* the corresponding network operators in
order to feel comfortable with the selection of resolver?

  o  To introduce the DNS Recursive Operator Privacy (DROP) statement
      and present a framework to assist writers of this document.  A
      DROP statement is a document that an operator can publish

(side note: I get that the acronym is cute, but it seems pretty clear that
the binding is "(DNS Recursive Operator) (Privacy Statement)" so the acronym
in a grammatical sense is misbound.)

      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.  In particular,

nit: *claimed* privacy properties.  (Absent an enforcement mechanism to
ensure that the actual practices match the documentation, as Section 6.3
alludes to.)

  A desired operational impact is that all operators (both those
  providing resolvers within networks and those operating large public
  services) can demonstrate their commitment to user privacy thereby
  driving all DNS resolution services to a more equitable footing.

side note: I'm having trouble explaining exactly why, but "more equitable"
sticks out at me, here.  It seems like maybe the intent is "to remove an
unneeded axis of variation among DNS resolution services"?

  Choices for users would (in this ideal world) be driven by other
  factors e.g. differing security policies or minor difference in
  operator policy rather than gross disparities in privacy concerns.

nit: commas before and after "e.g.", and comma before "rather".

Section 3

I'm not even sure that classifying as "increase"/"decrease" is accruate; my
take would be that the protocol changes present a different profile of
privacy-related properties that can increase or decrease privacy on many
different axes simultaneously.

Section 4

  DNS terminology is as described in [RFC8499] with one modification:
  we restate the clause in the original definition of Privacy-enabling
  DNS server in [RFC8310] to include the requirement that a DNS over
  (D)TLS server should also offer at least one of the credentials
  described in Section 8 of [RFC8310] and implement the (D)TLS profile
  described in Section 9 of [RFC8310].

Just to check: this text is saying that we use the 8310 definition and not
the 8499 definition, right?  (Not that we're adding on top of the 8310
definition?)

Section 5

In general I would have appreciated a bit more exposition about what the
threats entail and why they are threats -- the current formulation with
one-liners basically assumes that the reader already knows why this is a
threat.

  We describe two classes of threats:

(side note: it might be an interesting exercise to analyze the "DNS Privacy
Threats" to see which of them actually just reflect omissions in the 6973
prifacy model vs. DNS-specific threats)

  This document does not specify policy - only best practice, however
  for DNS Privacy services to be considered compliant with these best
  practice guidelines they SHOULD implement (where appropriate) all:

This normative "SHOULD" feels weird, as it in some sense is giving me
license to claim compliance when I do none of the listed things ("because
it's only a 'SHOULD'").  Perhaps just saying that we define the three levels
of compliance (with no normative language) is enough.

Section 5.1.1

      *  Passive surveillance of traffic on the wire
        [I-D.ietf-dprive-rfc7626-bis] Section 2.4.2.

nit: this is currently Section 3.4.2.

  It is also noted that DNS privacy service might be provided over
  IPSec, DNSCrypt, or VPNs.  However, use of these transports for DNS
  are not standardized and any discussion of best practice for
  providing such a service is out of scope for this document.

I don't think it's quite correct to say that usage of IPsec to provide
transport for DNS is "not standardized": you merely configure IPsec to
protect communications to the IP address(es) that you configure as your
resolver, and gain the protection of IPsec.  No DNS-layer protocol or
configuration changes are needed, though you do tend to need some kind of
prior configuration/agreement with the DNS server.

Section 5.1.2.1

  It is noted that SPKI pin set management is described in [RFC7858]
  but that key pinning mechanisms in general have fallen out of favor
  operationally for various reasons such as the logistical overhead of
  rolling keys.

If SPKI pin sets have fallen out of favor, why do we still list it as an
option in the previous section?

  DNS Privacy Threats:

  o  Invalid certificates, resulting in an unavailable service.

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

I'm not sure I understand how either of these is a "DNS Privacy threat".
How does a certificate spontaneously become an "invalid certificate" other
than by expiration or revocation?  How does a user mistyping a domain name
result in a privacy threat?

Section 5.1.3.1


  DNS Privacy Threats:

  o  Known attacks on TLS such as those described in [RFC7457].

The RFC 7457 attacks are pretty well-known and -mitigated at this point, and
they also don't particularly seem to be DNS-specific.  I'm not sure how much
value would be lost if we removed this bullet point.

  In the case of DNS-over-TLS, TLS profiles from Section 9 and the
  Countermeasures to DNS Traffic Analysis from section 11.1 of
  [RFC8310] provide strong mitigations.  This includes but is not

nit: I suggest adding the [RFC8310] reference for "Section 9" as well as
"Section 11.1" to avoid confusion (especially by the htmlization script used
by tools.ietf.org).

Interestingly, Section 9 of RFC 8310 recomments using (at that point, TLS
1.2) stateless session tickets, which themselves have privacy flaws by
virtue of allowing an attacker to correlate ticket issuance and use for TLS
resumption.  (TLS 1.3 tickets do not have this flaw in the recommended
usage.)

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

but is possible with the recently-allocated "dot" ALPN value:
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

Section 5.1.3.2

[same comment about RFC 7457]

  o  Potential for client tracking via transport identifiers.

Just to check: this is a single (fixed) DoH server tracking a moveable
client as the client contacts that server from multiple network addresses?
Specifically, it is not claiming that transport identifiers allow the client
to be tracked by an attacker "in the network"?

Section 5.1.4

Do we need to say anything about algorithm support (e.g., staying up to date
on them) or (root) key rolls, or refer to some other document thereto?

  DNS Privacy Threats:

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

This is just "if the clients get bogus DNS responses bad things happen",
right?  I'm not sure that this phrasing conveys the origin of the threat
very well.

Section 5.1.7

  when traffic between clients and resolvers is encrypted.  There are,
  however, legitimate reasons for DNS privacy service operators to
  inspect DNS traffic, e.g. to monitor for network security threats.

"Legitimate" is basically a subjective assessment and that assessment may
well change over time and depending on who you ask. As this is somewhat
buried in the middle of the document it's hard to have high confidence that
there is IETF consensus in this assessment.  Would you be open to an
alternate phrasing such as "Many DNS privacy service operators still have
need to inspect DNS traffic" that is clear this is a thing commonly done,
and done by operators aware of privacy considerations for DNS operation,
without implying that it will be so indefinitely?

Section 5.1.8

  o  Misconfiguration of the target server could lead to data leakage
      if the proxy to target server path is not encrypted.

I'm not sure I understand the path from misconfiguration to leakage, here --
to be clear, we're talking about misconfiguration of the (stock) DNS server
that's behind the TLS proxy?  What path does the leakage occur on?

Section 5.2.1

  The following are common activities for DNS service operators and in
  all cases should be minimized or completely avoided if possible for
  DNS privacy services.  If data is retained it should be encrypted and
  either aggregated, pseudonymized, or anonymized whenever possible.
  In general the principle of data minimization described in [RFC6973]
  should be applied.

nit: the following list is a list of recommendations, not a list of common
activities as the first sentence would have us believe.

  o  DNS privacy services should not track users except for the
      particular purpose of detecting and remedying technically
      malicious (e.g.  DoS) or anomalous use of the service.

I have mixed feelings about endorsing the tracking of mere "anomalous use"
(though I recognize that it's an operational reality for threat detection),
given that a lot of what human researchers may be doing will end up
classified as "anomalous".

  o  Data access should be minimized to only those personnel who
      require access to perform operational duties.  It should also be
      limited to anonymized or pseudonymized data were operationally
      feasible, with access to full logs (if any are held) only
      permitted when necessary.

nit: "were" should be eiher "where" or "when".

Section 5.2.3

I suggest adding the note "Legend of techniques:" to the caption of Table 1,
to clarify that those are what are being compared, and the row names are the
attributes in question.

Section 5.2.4

  o  Fingerprinting of the client application or TLS library by e.g.
      TLS version/Cipher suite combinations or other connection
      parameters.

(TLS Extensions are also a good fingerprinting mechanism, though there's not
a particular need to mention them, specifically.)

  o  HTTP headers (e.g., User-Agent, Accept, Accept-Encoding).

nit: is there a reason to not classify these as "Fingerprinting" mechanisms
akin to the first two bullet points?

Section 5.3.1

  Optimizations:

  o  The server should either:

      *  not use the ECS option in upstream queries at all, or

      *  offer alternative services, one that sends ECS and one that
        does not.

I'm not sure I understand the apparent recommendation to prefer no ECS at
all to ECS with a limited prefix length.  Is there a pointer handy to the WG
discussions?

  If operators do offer a service that sends the ECS options upstream
  they should use the shortest prefix that is operationally feasible
  and ideally use a policy of whitelisting upstream servers to send ECS
  to in order to minimize data leakage.  Operators should make clear in
  any policy statement what prefix length they actually send and the
  specific policy used.

I'll note that whitelisting is still subject to attack in the face of an RFC
3552 attacker unless the recursive/authoritative path is also secured and
the authoritative authenticated (whether by DNSSEC on the responses or a
transport-layer mechanism); this is probably worth discussion a little bit.

Section 5.3.3

  Operators should consider including specific guidelines for the
  collection of aggregated and/or anonymized data for research

nit: is this "including in a DROP statement"?

Section 6.1.2

  1.  Deviations.  Specify any temporary or permanent deviations from
      the policy for operational reasons.

Is it common for the folks doing the actual operational decision-making to
have to document it like this (versus this being a super-aspirational
"requirement" that's unlikely to be achieved in practice)?

      1.  For DoT, specify the authentication domain name to be used
          (if any).

Is it assumed that the client will already have (and know) a PKI trust
anchor (set) to use to validate the ADN?

Section 9

s/John Reed/Jon Reed/ ("for comments at the mic", I know, so spelling is
ambiguous...)

Section 12

One could argue that RFC 6265 is only informative (we basically say "you
have to let people *not* use this"); likewise for 7873.

Given the "must [...] perform DNSSEC validation" in Section 5.1.4 it seems
that RFC 4033 (or perhaps a companion document from the 403x series) would
be normative.
I think probably RFCs 5280, and maybe 8499, should be normative as well.
There are also a few references that are needed to meet the "additional
options", and from the stance that these are required in order to be
"maximally compliant" they would also be classified as normative, though I
did not attempt to tabulate them.

Section A.2

  o  [RFC8446] Appendix C.4 describes Client Tracking Prevention in TLS
      1.3

"Client tracking prevention" sounds like an increase, not a decrease, in DNS
privacy.

Section C.2

  1.  Deviations from Policy.  None currently in place.

Would we expect some indication of what "currently" means?

[Ballot comment]
In general, I support this document. It is good to help educate folks on what
should be included in a privacy statement, but as Alissa notes, there is no "one
size fits all". Especially if one implies a cookie cutter type of form with check
marks will be adequate to compare offerings. I don't think this is what was
intended - considering the detailed assessment on the DROP form - but
there's a couple of sentence stragglers that infer the DROP form is the form
*for all*.

Support Alissa's and Ben's Discuss.

A couple of my concerns:

5.3.3 Both Alissa (and Stephen previously) noted there is no meaningful way to obtain
explicit  "consent". Considering this document is a "best practice", suggest simply
removing, and recommending as Alissa says "not share".

6.1.2 #5 agree with Alissa - this should be removed.

6.2 "We note that the existing set of policies vary widely in style,
  content and detail and it is not uncommon for the full text for a
  given operator to equate to more than 10 pages of moderate font sized
  A4 text.  It is a non-trivial task today for a user to extract a
  meaningful overview of the different services on offer."

I'm not sure what this is trying to say? The purpose of this document is
to advocate for comprehensive privacy statements. As Alissa notes (2), this document
alone is not sufficient to give adequate description for a service.  This sentence implies
a 10-page document is bad because it is 10 pages (yet this document's DROP example
has 5 pages requiring detailed information and lists to complete). And the last sentence
negatively prejudges a user's reading capability or specific interest. Suggest drop the last
sentence and it will remove the negativity as I don't think the DROP example is any easier
on a user to read.

[Ballot discuss]
(1) Picking up on a Gen-ART review comment: Section 5.1.7 seems to be aimed at entities other than the operators of DNS privacy services. That is, the "impact" seems like it is on third-party entities, but then the "optimization" talks about DNS privacy service operators using "alternative means for traffic monitoring." I guess what I don't understand is why the DNS privacy service operators need alternative means, since they still have access to the cleartext.

(2) I think Section 6 needs to clarify that it is providing suggestions only on matters relating to the technical operation of DNS privacy services that may be described in DROP policies, and not on any other matters. There are numerous other matters that are typically addressed in privacy statements (e.g., what form of legal process the operator requires to supply data to law enforcement, how the operator handles data about children, etc.). This document should not give the impression that the listed items in the subsections are an exhaustive list, nor should it attempt to offer an exhaustive list.

(3) I do not think item #5 in Section 6.1.2 belongs in this document. I don't see how it is within scope for the IETF to be specifying these sorts of best practices.

[Ballot comment]
Section 1:

"This document does not, however,
      define a particular Privacy statement, nor does it seek to provide
      legal advice or recommendations as to the contents."

This is not accurate. The document does make recommendations about the contents.

Section 3: "the privacy of the DNS" strikes me as a bit of an odd term as the DNS itself doesn't have privacy needs. Perhaps this means the privacy properties of the DNS.

Section 5.2.3: I think the table and its associated text belongs in Appendix B. It is not BCP material itself and is not readily understandable without the rest of the text in Appendix B anyway.

Section 5.2.4: "Resolvers _might_ receive client identifiers e.g.  MAC addresses in EDNS(0) options - some Customer-premises equipment (CPE) devices are known to add them." It would be great to add a citation there if one exists.

Section 5.3.3:

"Operators should not provide identifiable data to third-parties
  without explicit consent from clients (we take the stance here that
  simply using the resolution service itself does not constitute
  consent)."

I'm not convinced its appropriate for this document to be commenting on what constitutes consent.

I also think that as a general matter the research in this area demonstrates that privacy-by-consent is broken and that the number of cases in which an individual providing consent for identifiable data sharing actually reads, understands, and agrees with the terms of the sharing is miniscule.

It seems like the real best current practice mitigation here is to not share identifiable data.

Section 6.1.1: "Make an explicit statement that IP addresses are treated as PII." PII is a bit of a jurisdiction-specific term. I would recommend using the definition of personal data from RFC 6973.

Section 6.2: This section should be an appendix.

Section A.2: I don't understand why the reference to Section 8 of RFC 8484 isn't just in the bulleted list with all the other documents, and why there is a generic note included with it when the specific privacy implications are more completely discussed in the referenced section of RFC 8484 (just like with the other documents in the list).

[Ballot comment]
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.

[Ballot comment]
** 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).

[Ballot discuss]
This document is trying to make normative references to sections of
draft-ietf-dprive-rfc7626-bis that have not existed since the -00 of that
document, with the content having been removed for being too controversial.
Do we need to delay processing this document until 7626bis has settled down
and it is clear what content we can refer to in that vs. needing to incorporate
into this document?  (It's unclear that such content would be less controversial
in this document than in that one.)
Specifically, Section 5.1.2 of this document refers to Section 2.5.3 of that document
("Rogue Servers").

[Ballot discuss]
This document is trying to make normative references to sections of
draft-ietf-dprive-rfc7626-bis that have not existed since the -01 of that
document, with the content having been removed for being too controversial.
Do we need to delay processing this document until 7626bis has settled down
and it is clear what content we can refer to in that vs. needing to incorporate
into this document?  (It's unclear that such content would be less controversial
in this document than in that one.)
Specifically, Section 5.1.2 of this document refers to Section 2.5.3 of that document
("Rogue Servers").

[Ballot comment]
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…

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dprive-bcp-op-07, which is currently in Last Call, and has the following comments:

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

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

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

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-01-02):

From: The IESG
To: IETF-Announce
CC: tjw.ietf@gmail.com, draft-ietf-dprive-bcp-op@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, dns-privacy@ietf.org, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Recommendations for DNS Privacy Service Operators) to Best Current Practice


The IESG has received a request from the DNS PRIVate Exchange WG (dprive) to
consider the following document: - 'Recommendations for DNS Privacy Service
Operators'
  as Best Current Practice

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
last-call@ietf.org mailing lists by 2020-01-02. 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 presents operational, policy and security
  considerations for DNS recursive resolver operators who choose to
  offer DNS Privacy services.  With these recommendations, the operator
  can make deliberate decisions regarding which services to provide,
  and how the decisions and alternatives impact the privacy of users.

  This document also presents a framework to assist writers of a DNS
  Recursive Operator Privacy Statement (analogous to DNS Security
  Extensions (DNSSEC) Policies and DNSSEC Practice Statements described
  in RFC6841).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8404: Effects of Pervasive Encryption on Operators (Informational - IETF stream)
    rfc8467: Padding Policies for Extension Mechanisms for DNS (EDNS(0)) (Experimental - IETF stream)
    rfc7828: The edns-tcp-keepalive EDNS0 Option (Proposed Standard - IETF stream)
    rfc8484: DNS Queries over HTTPS (DoH) (Proposed Standard - IETF stream)
    rfc6973: Privacy Considerations for Internet Protocols (Informational - IAB stream)
    rfc7766: DNS Transport over TCP - Implementation Requirements (Proposed Standard - IETF stream)
    rfc6265: HTTP State Management Mechanism (Proposed Standard - IETF stream)
    rfc8310: Usage Profiles for DNS over TLS and DNS over DTLS (Proposed Standard - IETF stream)
    rfc7626: DNS Privacy Considerations (Informational - IETF stream)
    rfc7830: The EDNS(0) Padding Option (Proposed Standard - IETF stream)
    rfc7873: Domain Name System (DNS) Cookies (Proposed Standard - IETF stream)
    rfc7858: Specification for DNS over Transport Layer Security (TLS) (Proposed Standard - IETF stream)
    rfc7871: Client Subnet in DNS Queries (Informational - IETF stream)
    draft-ietf-dprive-rfc7626-bis: DNS Privacy Considerations (None - IETF stream)
    rfc7816: DNS Query Name Minimisation to Improve Privacy (Experimental - IETF stream)

(1) Document is requested as Best Current Practice. This is the proper RFC type.

(2)

Technical Summary:

This document presents operational, policy and security
considerations for DNS recursive resolver operators who choose to
offer DNS Privacy services.  With these recommendations, the operator
can make deliberate decisions regarding which services to provide,
and how the decisions and alternatives impact the privacy of users.

Working Group Summary:

Working Group process was not controversial or rough.

Document Quality:

  Document quality is very solid and has been through several reviews.

Personnel:

Document Shepherd:  Tim Wicinski
Responsible Area Director:  Éric Vyncke

(3) The Document Shepherd did an extensive review of the document, and
feel it is ready for publication.

(4) Shepherd does not have any concerns about the depth or breadth of the
reviews

(5) Document does not need any broader review (outside of the normal area
reviews)

(6) Document Shepherd has no concerns with this document.

(7) No IPR Disclosures

(8) No IPR

(9) WG consensus is behind this document

(10) No Appeals

(11) There are several downward Normative References, which are discussed
in 15.  There is one additional nit where the document mentions the
obsoleted RFC5077 and not the updated RFC8446.  This is described in the
text referencing TLS and TLS1.2
    'such as TLS session resumption [RFC5077] with TLS 1.2, section 2.2 of RFC8446’

(12) No formal review needed

(13) All references HAVE been identified as either normative or
informative.

(14) There are no normative references that are not ready for advancement

(15) There are five downward normative references in this document.
As this is a BCP, it is describing best current practices which
include Informational and Experimental documents. These references are:

  ** Downref: Normative reference to an Experimental RFC: RFC 8467
  ** Downref: Normative reference to an Experimental RFC: RFC 7816
  ** Downref: Normative reference to an Informational RFC: RFC 6973
  ** Downref: Normative reference to an Informational RFC: RFC 7871
  ** Downref: Normative reference to an Informational RFC: RFC 8404

(16) Publication will not change the status of existing RFCS.

(17) No IANA Considerations

(18) No IANA Registries

(19) No automated checks

(20) No YANG

(1) Document is requested as Best Current Practice. This is the proper RFC type.

(2)

Technical Summary:

This document presents operational, policy and security
considerations for DNS recursive resolver operators who choose to
offer DNS Privacy services.  With these recommendations, the operator
can make deliberate decisions regarding which services to provide,
and how the decisions and alternatives impact the privacy of users.

Working Group Summary:

Working Group process was not controversial or rough.

Document Quality:

  Document quality is very solid and has been through several reviews.

Personnel:

Document Shepherd:  Tim Wicinski
Responsible Area Director:  Éric Vyncke

(3) The Document Shepherd did an extensive review of the document, and
feel it is ready for publication.

(4) Shepherd does not have any concerns about the depth or breadth of the
reviews

(5) Document does not need any broader review (outside of the normal area
reviews)

(6) Document Shepherd has no concerns with this document.

(7) No IPR Disclosures

(8) No IPR

(9) WG consensus is behind this document

(10) No Appeals

(11) There are several downward Normative References, which are discussed
in 15.  There is one additional nit where the document mentions the
obsoleted RFC5077 and not the updated RFC8446.  This is described in the
text referencing TLS and TLS1.2
    'such as TLS session resumption [RFC5077] with TLS 1.2, section 2.2 of RFC8446’

(12) No formal review needed

(13) All references HAVE been identified as either normative or
informative.

(14) There are no normative references that are not ready for advancement

(15) There are five downward normative references in this document.
As this is a BCP, it is describing best current practices which
include Informational and Experimental documents. These references are:

  ** Downref: Normative reference to an Experimental RFC: RFC 8467
  ** Downref: Normative reference to an Experimental RFC: RFC 7816
  ** Downref: Normative reference to an Informational RFC: RFC 6973
  ** Downref: Normative reference to an Informational RFC: RFC 7871
  ** Downref: Normative reference to an Informational RFC: RFC 8404

(16) Publication will not change the status of existing RFCS.

(17) No IANA Considerations

(18) No IANA Registries

(19) No automated checks

(20) No YANG