> On 5 Feb 2020, at 18:48, Alissa Cooper via Datatracker <[email protected]>
> wrote:
>
> 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:
> ----------------------------------------------------------------------
>
> (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.
>
What I tried to say in my response to Mohit is that is is *not* aimed at
entities other than the operators of DNS privacy services, it is aimed solely
at the operators of DNS privacy services. In a previous version the section was
called “Impact on DNS Privacy Service Operators” and I suggest updating the
title again to:
“Impact of Encryption on Monitoring by DNS Privacy Service Operators“
and also update the Threat text:
* Increased use of encryption can impact DNS privacy service operator ability
to monitor traffic and therefore manage
their DNS servers [RFC8404].
The point of the section is that historically DNS operators have frequently
implemented monitoring by capturing PCAPS of the network traffic directly
(often in a separate server) because the existing tools for logging inside the
DNS software were seen to have a significant detrimental effect on the
nameserver performance (I’ve seen 15-20% quoted for some of the available
tools). For operators not using a proxy they will have to switch to using an
built-in tool (if the implementation even has one, many don’t) and the section
was trying to highlight that issue.
>
> (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.
Suggest adding the following text after the first sentence in Section 6:
“ These recommendations:
* Aim to provide a consistent framework to facilitate comparison of DROP
statements between different operators.
* Relate *only* to matters around to the technical operation of DNS privacy
services, and not on any other matters.
* Are not, and do not attempt to offer an exhaustive list for the contents of a
DROP statement. "
>
> (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.
> 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.
I take the point about the implication of legal/compliance so suggest and
additional bullet point to those proposed for the start of section 6:
* Do not form the basis of any legal/compliance documentation
Or whatever form of words would be required to qualify this adequately...
> 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.
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
<https://en.wikipedia.org/wiki/Warrant_canary> ). It's not an issue that has no
grounds in reality.
>
>
> ----------------------------------------------------------------------
> 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
<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/
<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
<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
