[dns-privacy] Benjamin Kaduk's No Objection on draft-ietf-dprive-bcp-op-10: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dprive-bcp-op-10: 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:
----------------------------------------------------------------------

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.