Re: [dns-privacy] Alissa Cooper's Discuss on draft-ietf-dprive-bcp-op-08: (with DISCUSS and COMMENT)

[Allison Mankin <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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 <[e-mail]> 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.
>
>
>