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 and 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
