> On 4 Mar 2020, at 18:44, Ben Schwartz <bem...@google.com> wrote:
> On Wed, Mar 4, 2020 at 8:32 AM Sara Dickinson <s...@sinodun.com> wrote: > >> >> >> On 6 Feb 2020, at 16:52, Alexey Melnikov via Datatracker <nore...@ietf.org> >> 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 < >> bem...@google.com>: >> >> 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 > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
