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

[Sara Dickinson <[e-mail]>]

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

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

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"

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

WFM.

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

Will do.

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

Yes - that works.

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

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

Many thanks

Sara.

> 
> 
>> 
>> 
>> ## 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.
>> 
>> 
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy