Subject: Re: [dns-privacy] Alexey Melnikov's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

From: Sara Dickinson <[email-masked]>
Date: Wed, 4 Mar 2020 13:32:14 +0000

> On 6 Feb 2020, at 16:52, Alexey Melnikov via Datatracker <[email-masked]> wrote:
> 
> Alexey Melnikov 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:
> ----------------------------------------------------------------------
> 
> 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 <[email-masked]>:
> 
> 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”.
> 

Barry suggested this and additional grammatical improvements which I will make.

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

I think this is an important point to make and no-one has contested this at any point in the development of the draft (I suspect DPRIVE is a good audience for anyone who would know any different). 

RFC7626 already includes this text: 
“To our knowledge, there are no specific privacy laws for DNS data, in any country.  Interpreting general privacy laws like [data-protection-directive] (European Union) in the context of DNS traffic data is not an easy task, and we do not know a court precedent here.  See an interesting analysis in [sidn-entrada].”

I’m more than happy to qualify the text in this document with a ’To our knowledge, '… 

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

I think this is trying to capture the point that there are additional general considerations for an end user that an operator cannot control.

Suggest: 
“Privacy considerations specifically from the perspective of an end user (for example, choice of client software or resolver selection policies)..."

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

Ack - Ben K’s DISCUSS captures the problems with Section renumbering...

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

Is is potentially both -  section 2.5.3 (Rogue servers)  is now section 3.5.1.2 (Active Attacks on Resolver Configuration) in draft-ietf-dprive-rfc7626-bis-04 which describes the issues in detail. So I believe updating the bullet point to be

* Active attacks on resolver configuration as described in [I-D.ietf-dprive-rfc7626-bis] Section 3.5.1.2

(or whatever that section ends up being numbered) should do it?

> 
> ## 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.”

The Stubby client implements Keepalive and several test servers also use it:
https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/ <https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/>
Admittedly none of the big anycast services use it. 

How about moving it to a ‘Additional option’? 

Moving DSO to a separate sentence as you describe seems correct though as I am not aware of any implementation of that. 

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

I think it is currently there but a bit hidden in the distinction between transient and retained data and also : “ If data is retained it should be encrypted and either aggregated, pseudonymized, or anonymized whenever possible.”

So bullet 1 could have the following sentence added:

“Such transient data may be deemed to require inclusion of personal identifiers and should be handled with appropriate care.”

and bullet two the following:

“Data retained for any period of time should use data minimisation techniques to remove personal identifiers."

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

Ben K also made a comment on this...

RFC7871 (which is only Informational) admits in the abstract that “... it has some known operational and privacy shortcomings” and section 2 suggests it should be disabled by default in client software and clients should be able to opt-out.

The first bullet point (honouring the SOURCE PREFIX-LENGTH) is already specified in RFC8310.

This document also has only limited scope… I would say that this text has DPRIVE consensus for its application specifically to DNS privacy services. 

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

Alissa suggested replacing with the definition of personal data from RFC 6973, which seems better. 

Best regards

Sara.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 4 Mar 2020 13:44:02 -0500

On Wed, Mar 4, 2020 at 8:32 AM Sara Dickinson <[email-masked]> wrote:

> I think this is an important point to make and no-one has contested this
> at any point in the development of the draft (I suspect DPRIVE is a good
> audience for anyone who would know any different).
>
> “To our knowledge, there are no specific privacy laws for DNS data, in any
> country.  Interpreting general privacy laws like
> [data-protection-directive] (European Union) in the context of DNS traffic
> data is not an easy task, and we do not know a court precedent here.  See
> an interesting analysis in [sidn-entrada].”
>

I don't especially like the text in RFC 7626 either (do we really have IETF
consensus on the ease or difficulty of reading particular laws?).  However,
I do think it's better than the text here.  "We do not know of a court
precedent" is appropriately qualified, and the implied claim ("there is no
court precedent") is close to factual in nature.  In contrast, "it is an
untested area" sounds less like a fact, and more like a legal opinion or
analysis offered by the IETF.

> I think this is trying to capture the point that there are additional
> general considerations for an end user that an operator cannot control.
>
> Suggest:
> “Privacy considerations specifically from the perspective of an end user
> (for example, choice of client software or resolver selection policies)..."
>

I still don't understand.  Perhaps "Choices that are made exclusively by
the end user ... are out of scope"?

> Is is potentially both -  section 2.5.3 (Rogue servers)  is now
> section 3.5.1.2 (Active Attacks on Resolver Configuration)
> in draft-ietf-dprive-rfc7626-bis-04 which describes the issues in detail.
> So I believe updating the bullet point to be
>
> * Active attacks on resolver configuration as described in
> [I-D.ietf-dprive-rfc7626-bis] Section 3.5.1.2
>

OK.

> https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/

Sounds good to me.

>
> Moving DSO to a separate sentence as you describe seems correct though as
> I am not aware of any implementation of that.
>
>
> I think it is currently there but a bit hidden in the distinction between
> transient and retained data and also : “ If data is retained it should be
> encrypted and either aggregated, pseudonymized, or anonymized whenever
> possible.”
>
> “Such transient data may be deemed to require inclusion of personal
> identifiers and should be handled with appropriate care.”
>
> “Data retained for any period of time should use data minimisation
> techniques to remove personal identifiers."
>

Sure.  I would say "such as IP addresses", since they are almost always the
only personal identifiers.

> RFC7871 (which is only Informational) admits in the abstract that “... it
> has some known operational and privacy shortcomings” and section 2
> suggests it should be disabled by default in client software and clients
> should be able to opt-out.
>

That bullet currently says "Honor a SOURCE PREFIX-LENGTH set to 0 ... and
not send an ECS option in upstream queries."  This conjunction is
ambiguous.  It also creates a needless technical conflict with RFC 7871,
which says "The subsequent Recursive Resolver query to the Authoritative
Nameserver will then either not include an ECS option or MAY optionally
include its own address information".

I would suggest "Honor a SOURCE PREFIX-LENGTH set to 0 ([RFC 7871] Section
7.1.2).", and avoid restating the required behavior.

This document also has only limited scope… I would say that this text has
> DPRIVE consensus for its application specifically to DNS privacy services.
>

All the other optimization sections are described as bare actions for the
operator to take.  Only this one contains normative language.  I would
suggest removing the "should".

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 5 Mar 2020 13:34:59 +0000

> On 4 Mar 2020, at 18:44, Ben Schwartz <[email-masked]> wrote:

> analysis offered by the IETF.

How about:

“We do not know of a court precedent relating to the question of whether simply using a DNS resolution service constitutes consent from the user for the operator to process their query data"

>> (for example, choice of client software or resolver selection policies)...."
>> 
> 
> the end user ... are out of scope”?

WFM.

> only personal identifiers.

Will do.

> 7.1.2).", and avoid restating the required behavior.

Yes - that works.

>> DPRIVE consensus for its application specifically to DNS privacy services..
>> 
> 
> suggest removing the "should”.

This lower case ’should' is not intended as normative but happy to modify for clarity.

Many thanks

Sara.

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 5 Mar 2020 12:13:41 -0500

On Thu, Mar 5, 2020, 8:35 AM Sara Dickinson <[email-masked]> wrote:

>
> How about:
>
> “We do not know of a court precedent relating to the question of whether
> simply using a DNS resolution service constitutes consent from the user for
> the operator to process their query data"
>

That sounds like a significant improvement to me.

Note that "precedent" is a term used by primarily in "common law"
jurisdictions like the UK and US, so it may not be meaningful to all
readers: https://en.wikipedia.org/wiki/Precedent#Civil_law_systems

> This lower case ’should' is not intended as normative but happy to modify

Thanks.

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 6 Mar 2020 11:39:58 +0100 (CET)

>     Il 05/03/2020 18:13 Ben Schwartz <bemasc=[email-masked]> ha scritto:
> 
> 
> 
> 
> 
>     On Thu, Mar 5, 2020, 8:35 AM Sara Dickinson < [email-masked] mailto:[email-masked] > wrote:
> 
>         > >         How about:
> > 
>     Note that "precedent" is a term used by primarily in "common law" jurisdictions like the UK and US, so it may not be meaningful to all readers:  https://en.wikipedia.org/wiki/Precedent#Civil_law_systems
> 
The concept is well understood in civil law systems as well, just precedents are not (that) binding.
Ciao,

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy