> On 6 Feb 2020, at 16:52, Alexey Melnikov via Datatracker <[email protected]> > 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 protected]>: > > 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.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
