[dns-privacy] Alissa Cooper's Discuss on draft-ietf-dprive-bcp-op-08: (with DISCUSS and COMMENT)
Alissa Cooper via Datatracker <noreply@ietf.org> Thu, 06 February 2020 17:39 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: dns-privacy@ietf.org
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7211200B9; Thu, 6 Feb 2020 09:39:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dprive-bcp-op@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dprive-chairs@ietf.org, tjw.ietf@gmail.com, dns-privacy@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.117.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alissa Cooper <alissa@cooperw.in>
Message-ID: <158101077704.5326.15327853108486418926.idtracker@ietfa.amsl.com>
Date: Thu, 06 Feb 2020 09:39:37 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/5TuXoH4nTCbUCGs21mDZyQAfrDI>
Subject: [dns-privacy] Alissa Cooper's Discuss on draft-ietf-dprive-bcp-op-08: (with DISCUSS and COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2020 17:39:37 -0000
Alissa Cooper has entered the following ballot position for draft-ietf-dprive-bcp-op-08: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have added more detail to point #3 below as requested on today's telechat. (1) Picking up on a Gen-ART review comment: Section 5.1.7 seems to be aimed at entities other than the operators of DNS privacy services. That is, the "impact" seems like it is on third-party entities, but then the "optimization" talks about DNS privacy service operators using "alternative means for traffic monitoring." I guess what I don't understand is why the DNS privacy service operators need alternative means, since they still have access to the cleartext. (2) I think Section 6 needs to clarify that it is providing suggestions only on matters relating to the technical operation of DNS privacy services that may be described in DROP policies, and not on any other matters. There are numerous other matters that are typically addressed in privacy statements (e.g., what form of legal process the operator requires to supply data to law enforcement, how the operator handles data about children, etc.). This document should not give the impression that the listed items in the subsections are an exhaustive list, nor should it attempt to offer an exhaustive list. (3) I do not think item #5 in Section 6.1.2 belongs in this document. I don't see how it is within scope for the IETF to be specifying these sorts of best practices, which are not technical or operational in nature but focus on legal matters and likely require the involvement of lots of lawyers in order to get the provisions written. This section implies that the DROP documents would become legal/compliance documents by nature, which may or may not be a good choice but is not within the remit of the IETF to specify. Also, I think what this section asks for is not the norm today and therefore it seems odd for the IETF to specify a best practice that operators may not have any chance of being able to comply with (e.g., listing specific law enforcement agencies, privacy laws, or countries where data centers will reside and the data will never move from them). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1: "This document does not, however, define a particular Privacy statement, nor does it seek to provide legal advice or recommendations as to the contents." This is not accurate. The document does make recommendations about the contents. Section 3: "the privacy of the DNS" strikes me as a bit of an odd term as the DNS itself doesn't have privacy needs. Perhaps this means the privacy properties of the DNS. Section 5.2.3: I think the table and its associated text belongs in Appendix B. It is not BCP material itself and is not readily understandable without the rest of the text in Appendix B anyway. Section 5.2.4: "Resolvers _might_ receive client identifiers e.g. MAC addresses in EDNS(0) options - some Customer-premises equipment (CPE) devices are known to add them." It would be great to add a citation there if one exists. Section 5.3.3: "Operators should not provide identifiable data to third-parties without explicit consent from clients (we take the stance here that simply using the resolution service itself does not constitute consent)." I'm not convinced its appropriate for this document to be commenting on what constitutes consent. I also think that as a general matter the research in this area demonstrates that privacy-by-consent is broken and that the number of cases in which an individual providing consent for identifiable data sharing actually reads, understands, and agrees with the terms of the sharing is miniscule. It seems like the real best current practice mitigation here is to not share identifiable data. Section 6.1.1: "Make an explicit statement that IP addresses are treated as PII." PII is a bit of a jurisdiction-specific term. I would recommend using the definition of personal data from RFC 6973. Section 6.2: This section should be an appendix. Section A.2: I don't understand why the reference to Section 8 of RFC 8484 isn't just in the bulleted list with all the other documents, and why there is a generic note included with it when the specific privacy implications are more completely discussed in the referenced section of RFC 8484 (just like with the other documents in the list).
- [dns-privacy] Alissa Cooper's Discuss on draft-ie… Alissa Cooper via Datatracker