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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Sat, 27 Jun 2020 17:10:05 -0700

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.

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 29 Jun 2020 17:47:23 +0100

> On 28 Jun 2020, at 01:10, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

Many thanks for the detailed review of -10.

> the reluctance to update at this stage is misplaced.

You are quite right - my apologies - this text was in the very first draft of the BCP and is not in RFC7626!

You previously proposed 
“Therefore, 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.”

which seems reasonable. Will update. 

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

Good catch - bullet added to the wrong list in -10! Fixed.

> that we're giving recommendations for?

Suggest: “and in all cases data retention should be minimized or completely avoided “

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

Both fixed. 

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

I see the ambiguity (and the outdated section reference after a renumber). I think this should read:

"With reference to each subsection of Section 5.1 provide specific details of which capabilities (transport, DNSSEC, padding, etc.) are provided on which client facing address/port combination or DoH URI template. For Section 5.1.2, clearly state which specific authentication mechanisms are supported for each endpoint that offers DoT:

* The authentication domain name to be used (if any).
* The SPKI pin sets to be used (if any) and policy for rolling keys.”

IIRC the bullets were added just for clarity as none, one or both mechanisms might be used by a particular end point.

> DoT+DoH as well as RFC 7766.  Arguably, those for DNSSEC as well.

Yes - I’ll add. 

> 8490, making them normative.

Done.

> these mechanisms that might lead to increased identification/tracking.

Done.
 
> being deanonymized, i.e., the causality reversed from my above

Suggest:  

"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, if an attacker can 
* ensure packets are captured by the target and
* send forged traffic with arbitrary source and destination addresses to that target and
* obtain a de-identified log of said traffic from that target
any format-preserving pseudonymization is vulnerable to an attack along the lines of a cryptographic chosen plaintext attack.

> use, perhaps there is not additional value from mentioning these names.

The term 'black-marker anonymization’ is used throughout RFC6235 (which is the basis of this categorisation) and in other sources but I don’t see grey-marker used there and I’m struggling to remember where it came from… Re-reading RFC6235 I think ’truncation’ is more correct:

"* Filtering. Removing or replacing data in a field. Field
    data can be overwritten, often with zeros, either partially (truncation or reverse truncation) or
    completely (black-marker anonymization)."

and later in the section s/grey marking/truncation/ 

> for the various (logging) operations, relating to (e.g.) recorrelation

Suggest:

OLD:
   +  Absolute arrival time

NEW:
   +  Absolute arrival time using a precision of ms

Thanks

Sara.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 29 Jun 2020 10:59:43 -0700

(inline)

> which seems reasonable. Will update. 

Thank you!

> Suggest: “and in all cases data retention should be minimized or completely avoided “

That matches what I expected; thanks

> IIRC the bullets were added just for clarity as none, one or both mechanisms might be used by a particular end point.

The bullets always seemed reasonable to me, and I think your "this should
read" looks good.  Thanks!

> any format-preserving pseudonymization is vulnerable to an attack along the lines of a cryptographic chosen plaintext attack.

That works for me, thanks again.

> The term 'black-marker anonymization’ is used throughout RFC6235 (which is the basis of this categorisation) and in other sources but I don’t see grey-marker used there and I’m struggling to rememb…

Ah, I hadn't pulled up 6235.

> and later in the section s/grey marking/truncation/ 

Sure.

>    +  Absolute arrival time using a precision of ms

Okay, thanks.  The reader will have to do their own analysis of what kind
of recorrelation ms precision admits, but that seems unavoiadable in some
sense; what's important is that the reader has enough information to do so.

Thanks for the updates,

Ben