Clarification: we no longer mention or imply mention of jurisdiction in the normative section. And to reiterate, we made 6.1.1 and 6.1.2 non-normative
On Sun, Jun 28, 2020 at 16:11 Allison Mankin <[email protected]> wrote: > Hi Alissa, > > Please read the -10 version. We've addressed this Discuss by omitting any > mention of jurisdiction and marking all texts in the DROP statement section > as non-normative. > > Sara references the change in the June 18 email with subject line: IESG > review of draft-IETF-DPRIVE-BCP-op > > Here's the new top of Section 6; is this enough to satisfy your Discuss? > > The contents of Section 6.1.1 > <https://datatracker.ietf.org/doc/html/draft-ietf-dprive-bcp-op-10#section-6.1.1> > and Section 6.1.2 > <https://datatracker.ietf.org/doc/html/draft-ietf-dprive-bcp-op-10#section-6.1.2> > are non-normative, > other than the order of the headings. Material under each topic is > present to assist the operator developing their own DROP statement > and: > > o Relates _only_ to matters around to the technical operation of DNS > privacy services, and not on any other matters. > > o Does not attempt to offer an exhaustive list for the contents of a > DROP statement. > > o Is not intended to form the basis of any legal/compliance > documentation. > > > On Jun 28, 2020, at 14:43, Alissa Cooper <[email protected]> wrote: > > Hi Sara, > > > Thanks for your response and the updates to the document. I’ve trimmed my > DISCUSS down to the remaining issue. > > On Mar 4, 2020, at 8:29 AM, Sara Dickinson <[email protected]> wrote: > > > (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. > > > I’m channelling Vittoro here (cc’ed) who as a Head of Policy helped to > formulate this text… > > The reason this was included is that the actual policy that will apply to > the data is the merge of the operator's privacy policy and of the relevant > jurisdiction's privacy laws, with the latter overriding the former in case > of conflict. Since the former is in scope for the DROP it seems reasonable > for the latter to be. If the goal here is to provide a document that > informs users of what will actually be done with their data, then outlining > which privacy laws will apply to them and how these laws will play out > seems reasonable. > > > I don’t really see how the above is responsive to my point. This is not > the IETF’s area of expertise and therefore we should not be specifying best > practices about it. Every IETF technology exists within a framework of laws > and regulations that vary by jurisdiction, but we don’t specify best > practices about them because they aren’t within our scope. We also don’t > want our RFCs to be obsolete because one country or region decides to > change its laws — we’re aiming for global significance. > > > 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). > > > It's also not true that supplying this information is "not the norm > today". Any GDPR-compliant privacy policy must specify the legal entity > processing the information, its place of business, the user's rights, and > whether the information will be moved to third countries. Basically, points > 5.1-5.3 only turn into best practice what the GDPR mandates in Europe - and > there is little doubt among privacy experts that the GDPR is the current > global best practice in terms of privacy laws. > > > The IETF operates globally and I think endorsing the idea of fracturing > data management and protection along jurisdictional lines is far from a > best practice that the body of the IETF’s work endorses. > > > As for 5.4, there are already significant efforts for the disclosure of > law enforcement access, even in the US and even with creative ways to > circumvent legal issues (see https://en.wikipedia.org/wiki/Warrant_canary ). > It's not an issue that has no grounds in reality. > > > > Best, > Alissa > > > > > > ---------------------------------------------------------------------- > 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. > > > Will remove ‘or recommendations’. > > > > 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. > > > Yes - will update. > > > 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. > > > Fair enough - will move this. > > > 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. > > > Yes - will add. > > > 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. > > > I appreciate the difficulties with this, but several aspects of this draft > have got push back on the basis of how many operators actually employ the > ‘best practice’. The reality is that many of the large recursive operators > currently make some statement about the DNS service or in an umbrella > privacy statement to the effect that they will share data if they have > consent (and then completely fail to describe what that consent entails), > for example: > > https://www.cisco.com/c/en/us/about/legal/privacy-full.html (Overall > policy which appears to apply to OpenDNS - OpenDNS doesn’t seem to have a > specific one) > We may share your personal information with third parties for the purposes > of operating our business, delivering, improving, and customizing > our Solutions, sending marketing and other communications related to our > business, and for other legitimate purposes permitted by applicable law > or otherwise with your consent. > > > https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/privacy-policy/ > Cloudflare will not sell, license, sublicense, or grant any rights to your > data that we collect from DNS queries to any other person or entity without > your consent. > > https://policies.google.com/privacy?hl=en (Overall policy referenced from > the Google Public DNS privacy policy page) > We’ll share personal information outside of Google when we have your > consent. > > > It is somewhat frustrating that this draft doesn't tackle this issue in > any meaningful way. We had previously included a clause in the DROP > statement where the operator was recommended to outline their specific > consent process (so in other words, not defining consent in this document > in any way, just requiring operators to clarify how _they_ define it given > they have used the word) but this received some push back. > > Adding an optimisation describing the ideal position (not sharing) seems > reasonable, as would adding any additional text to clarify the limitations > of the definition of consent in this document, but removing it completely > would mean virtually no large operators would ever be even minimally > compliant….. > > > > 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. > > > Ack. > > > Section 6.2: This section should be an appendix. > > > That’s fine. > > > 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). > > > I think that text came in before RFC8484 was published and section 8 was > quite limited, happy to convert to a bullet point. > > Best regards > > Sara. > > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
