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

[Ben Schwartz <[e-mail]>]

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

>
>
> 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, '…
>

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.

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

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


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

OK.

>
>
> ## 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/
> Admittedly none of the big anycast services use it.
>
> How about moving it to a ‘Additional option’?
>

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

Sure.  I would say "such as IP addresses", since they are almost always the
only 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.
>

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


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