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

[Sara Dickinson <[e-mail]>]

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