draft-ietf-dprive-bcp-op-11.txt   draft-ietf-dprive-bcp-op-12.txt 
dprive S. Dickinson dprive S. Dickinson
Internet-Draft Sinodun IT Internet-Draft Sinodun IT
Intended status: Best Current Practice B. Overeinder Intended status: Best Current Practice B. Overeinder
Expires: January 3, 2021 R. van Rijswijk-Deij Expires: January 7, 2021 R. van Rijswijk-Deij
NLnet Labs NLnet Labs
A. Mankin A. Mankin
Salesforce Salesforce
July 2, 2020 July 6, 2020
Recommendations for DNS Privacy Service Operators Recommendations for DNS Privacy Service Operators
draft-ietf-dprive-bcp-op-11 draft-ietf-dprive-bcp-op-12
Abstract Abstract
This document presents operational, policy, and security This document presents operational, policy, and security
considerations for DNS recursive resolver operators who choose to considerations for DNS recursive resolver operators who choose to
offer DNS Privacy services. With these recommendations, the operator offer DNS Privacy services. With these recommendations, the operator
can make deliberate decisions regarding which services to provide, can make deliberate decisions regarding which services to provide,
and how the decisions and alternatives impact the privacy of users. and how the decisions and alternatives impact the privacy of users.
This document also presents a non-normative framework to assist This document also presents a non-normative framework to assist
writers of a DNS Recursive Operator Privacy Statement (analogous to writers of a Recursive operator Privacy statement (analogous to DNS
DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements
Statements described in RFC6841). described in RFC6841).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2021. This Internet-Draft will expire on January 7, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 14
5.2.2. Data minimization of network traffic . . . . . . . . 15 5.2.2. Data minimization of network traffic . . . . . . . . 15
5.2.3. IP address pseudonymization and anonymization methods 16 5.2.3. IP address pseudonymization and anonymization methods 16
5.2.4. Pseudonymization, anonymization, or discarding of 5.2.4. Pseudonymization, anonymization, or discarding of
other correlation data . . . . . . . . . . . . . . . 16 other correlation data . . . . . . . . . . . . . . . 16
5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17 5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17
5.3. Data sent onwards from the server . . . . . . . . . . . . 17 5.3. Data sent onwards from the server . . . . . . . . . . . . 17
5.3.1. Protocol recommendations . . . . . . . . . . . . . . 17 5.3.1. Protocol recommendations . . . . . . . . . . . . . . 17
5.3.2. Client query obfuscation . . . . . . . . . . . . . . 18 5.3.2. Client query obfuscation . . . . . . . . . . . . . . 18
5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19 5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19
6. DNS Recursive Operator Privacy (DROP) statement . . . . . . . 19 6. Recursive operator Privacy Statement (RPS) . . . . . . . . . 19
6.1. Outline of a DROP statement . . . . . . . . . . . . . . . 20 6.1. Outline of an RPS . . . . . . . . . . . . . . . . . . . . 20
6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20 6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20
6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21 6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Enforcement/accountability . . . . . . . . . . . . . . . 22 6.2. Enforcement/accountability . . . . . . . . . . . . . . . 22
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Security considerations . . . . . . . . . . . . . . . . . . . 22 8. Security considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
skipping to change at page 3, line 23 skipping to change at page 3, line 23
B.1. Categorization of techniques . . . . . . . . . . . . . . 36 B.1. Categorization of techniques . . . . . . . . . . . . . . 36
B.2. Specific techniques . . . . . . . . . . . . . . . . . . . 37 B.2. Specific techniques . . . . . . . . . . . . . . . . . . . 37
B.2.1. Google Analytics non-prefix filtering . . . . . . . . 37 B.2.1. Google Analytics non-prefix filtering . . . . . . . . 37
B.2.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . 37 B.2.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . 37
B.2.3. Prefix-preserving map . . . . . . . . . . . . . . . . 38 B.2.3. Prefix-preserving map . . . . . . . . . . . . . . . . 38
B.2.4. Cryptographic Prefix-Preserving Pseudonymization . . 38 B.2.4. Cryptographic Prefix-Preserving Pseudonymization . . 38
B.2.5. Top-hash Subtree-replicated Anonymization . . . . . . 38 B.2.5. Top-hash Subtree-replicated Anonymization . . . . . . 38
B.2.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . 39 B.2.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . 39
B.2.7. Bloom filters . . . . . . . . . . . . . . . . . . . . 39 B.2.7. Bloom filters . . . . . . . . . . . . . . . . . . . . 39
Appendix C. Current policy and privacy statements . . . . . . . 39 Appendix C. Current policy and privacy statements . . . . . . . 39
Appendix D. Example DROP statement . . . . . . . . . . . . . . . 40 Appendix D. Example RPS . . . . . . . . . . . . . . . . . . . . 40
D.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 40 D.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 40
D.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 43 D.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
The Domain Name System (DNS) is at the core of the Internet; almost The Domain Name System (DNS) is at the core of the Internet; almost
every activity on the Internet starts with a DNS query (and often every activity on the Internet starts with a DNS query (and often
several). However the DNS was not originally designed with strong several). However the DNS was not originally designed with strong
security or privacy mechanisms. A number of developments have taken security or privacy mechanisms. A number of developments have taken
skipping to change at page 4, line 36 skipping to change at page 4, line 36
significant activity. Providing detailed practice advice about these significant activity. Providing detailed practice advice about these
areas to the operator is out of scope, but Section 5.3.3 describes areas to the operator is out of scope, but Section 5.3.3 describes
some mitigations of data sharing risk. some mitigations of data sharing risk.
This document has two main goals: This document has two main goals:
o To provide operational and policy guidance related to DNS over o To provide operational and policy guidance related to DNS over
encrypted transports and to outline recommendations for data encrypted transports and to outline recommendations for data
handling for operators of DNS privacy services. handling for operators of DNS privacy services.
o To introduce the DNS Recursive Operator Privacy (DROP) statement o To introduce the Recursive operator Privacy Statement (RPS) and
and present a framework to assist writers of a DROP statement. A present a framework to assist writers of an RPS. An RPS is a
DROP statement is a document that an operator should publish which document that an operator should publish which outlines their
outlines their operational practices and commitments with regard operational practices and commitments with regard to privacy,
to privacy, thereby providing a means for clients to evaluate both thereby providing a means for clients to evaluate both the
the measurable and claimed privacy properties of a given DNS measurable and claimed privacy properties of a given DNS privacy
privacy service. The framework identifies a set of elements and service. The framework identifies a set of elements and specifies
specifies an outline order for them. This document does not, an outline order for them. This document does not, however,
however, define a particular Privacy statement, nor does it seek define a particular privacy statement, nor does it seek to provide
to provide legal advice as to the contents. legal advice as to the contents.
A desired operational impact is that all operators (both those A desired operational impact is that all operators (both those
providing resolvers within networks and those operating large public providing resolvers within networks and those operating large public
services) can demonstrate their commitment to user privacy thereby services) can demonstrate their commitment to user privacy thereby
driving all DNS resolution services to a more equitable footing. driving all DNS resolution services to a more equitable footing.
Choices for users would (in this ideal world) be driven by other Choices for users would (in this ideal world) be driven by other
factors, e.g., differing security policies or minor difference in factors, e.g., differing security policies or minor difference in
operator policy, rather than gross disparities in privacy concerns. operator policy, rather than gross disparities in privacy concerns.
Community insight [or judgment?] about operational practices can Community insight [or judgment?] about operational practices can
skipping to change at page 6, line 22 skipping to change at page 6, line 22
DNS terminology is as described in [RFC8499] with one modification: DNS terminology is as described in [RFC8499] with one modification:
we restate the clause in the original definition of Privacy-enabling we restate the clause in the original definition of Privacy-enabling
DNS server in [RFC8310] to include the requirement that a DNS over DNS server in [RFC8310] to include the requirement that a DNS over
(D)TLS server should also offer at least one of the credentials (D)TLS server should also offer at least one of the credentials
described in Section 8 of [RFC8310] and implement the (D)TLS profile described in Section 8 of [RFC8310] and implement the (D)TLS profile
described in Section 9 of [RFC8310]. described in Section 9 of [RFC8310].
Other Terms: Other Terms:
o DROP: DNS Recursive Operator Privacy statement, see Section 6. o RPS: Recursive operator Privacy Statement, see Section 6.
o DNS privacy service: The service that is offered via a privacy- o DNS privacy service: The service that is offered via a privacy-
enabling DNS server and is documented either in an informal enabling DNS server and is documented either in an informal
statement of policy and practice with regard to users privacy or a statement of policy and practice with regard to users privacy or a
formal DROP statement. formal RPS.
5. Recommendations for DNS privacy services 5. Recommendations for DNS privacy services
In the following sections we first outline the threats relevant to In the following sections we first outline the threats relevant to
the specific topic and then discuss the potential actions that can be the specific topic and then discuss the potential actions that can be
taken to mitigate them. taken to mitigate them.
We describe two classes of threats: We describe two classes of threats:
o Threats described in [RFC6973] 'Privacy Considerations for o Threats described in [RFC6973] 'Privacy Considerations for
skipping to change at page 19, line 46 skipping to change at page 19, line 46
specific circumstance they should publish the terms under which data specific circumstance they should publish the terms under which data
is shared. is shared.
Operators should consider including specific guidelines for the Operators should consider including specific guidelines for the
collection of aggregated and/or anonymized data for research collection of aggregated and/or anonymized data for research
purposes, within or outside of their own organization. This can purposes, within or outside of their own organization. This can
benefit not only the operator (through inclusion in novel research) benefit not only the operator (through inclusion in novel research)
but also the wider Internet community. See the policy published by but also the wider Internet community. See the policy published by
SURFnet [SURFnet-policy] on data sharing for research as an example. SURFnet [SURFnet-policy] on data sharing for research as an example.
6. DNS Recursive Operator Privacy (DROP) statement 6. Recursive operator Privacy Statement (RPS)
To be compliant with this Best Common Practices document, a DNS To be compliant with this Best Common Practices document, a DNS
Recursive Operator SHOULD publish a DNS Recursive Operator Privacy recursive operator SHOULD publish a Recursive operator Privacy
Statement. Adopting the outline, and including the headings in the Statement (RPS). Adopting the outline, and including the headings in
order provided, is a benefit to persons comparing multiple operators' the order provided, is a benefit to persons comparing RPSs from
DROP statements. multiple operators.
Appendix C provides a comparison of some existing policy and privacy Appendix C provides a comparison of some existing policy and privacy
statements. statements.
6.1. Outline of a DROP statement 6.1. Outline of an RPS
The contents of Section 6.1.1 and Section 6.1.2 are non-normative, 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 other than the order of the headings. Material under each topic is
present to assist the operator developing their own DROP statement present to assist the operator developing their own RPS and:
and:
o Relates _only_ to matters around to the technical operation of DNS o Relates _only_ to matters around to the technical operation of DNS
privacy services, and not on any other matters. privacy services, and not on any other matters.
o Does not attempt to offer an exhaustive list for the contents of a o Does not attempt to offer an exhaustive list for the contents of
DROP statement. an RPS.
o Is not intended to form the basis of any legal/compliance o Is not intended to form the basis of any legal/compliance
documentation. documentation.
Appendix D provides an example (also non-normative) of a DROP Appendix D provides an example (also non-normative) of an RPS
statement for a specific operator scenario. statement for a specific operator scenario.
6.1.1. Policy 6.1.1. Policy
1. Treatment of IP addresses. Make an explicit statement that IP 1. Treatment of IP addresses. Make an explicit statement that IP
addresses are treated as personal data. addresses are treated as personal data.
2. Data collection and sharing. Specify clearly what data 2. Data collection and sharing. Specify clearly what data
(including IP addresses) is: (including IP addresses) is:
skipping to change at page 22, line 38 skipping to change at page 22, line 38
o ECS, QNAME minimization, EDNS(0) padding, etc. o ECS, QNAME minimization, EDNS(0) padding, etc.
o Filtering. o Filtering.
o Uptime. o Uptime.
This is by analogy with several TLS or website analysis tools that This is by analogy with several TLS or website analysis tools that
are currently available e.g., [SSL-Labs] or [Internet.nl]. are currently available e.g., [SSL-Labs] or [Internet.nl].
Additionally operators could choose to engage the services of a third Additionally operators could choose to engage the services of a third
party auditor to verify their compliance with their published DROP party auditor to verify their compliance with their published RPS.
statement.
7. IANA considerations 7. IANA considerations
None None
8. Security considerations 8. Security considerations
Security considerations for DNS-over-TCP are given in [RFC7766], many Security considerations for DNS-over-TCP are given in [RFC7766], many
of which are generally applicable to session based DNS. Guidance on of which are generally applicable to session based DNS. Guidance on
operational requirements for DNS-over-TCP are also available in [I- operational requirements for DNS-over-TCP are also available in [I-
D.dnsop-dns-tcp-requirements]. Security considerations for DoT are D.dnsop-dns-tcp-requirements]. Security considerations for DoT are
given in [RFC7858] and [RFC8310], those for DoH in [RFC8484]. given in [RFC7858] and [RFC8310], those for DoH in [RFC8484].
Security considerations for DNSSEC are given in [RFC4033], [RFC4034] Security considerations for DNSSEC are given in [RFC4033], [RFC4034]
and [RFC4035]. and [RFC4035].
9. Acknowledgements 9. Acknowledgements
Many thanks to Amelia Andersdotter for a very thorough review of the Many thanks to Amelia Andersdotter for a very thorough review of the
first draft of this document and Stephen Farrell for a thorough first draft of this document and Stephen Farrell for a thorough
review at WGLC and for suggesting the inclusion of an example DROP review at WGLC and for suggesting the inclusion of an example RPS.
statement. Thanks to John Todd for discussions on this topic, and to Thanks to John Todd for discussions on this topic, and to Stephane
Stephane Bortzmeyer, Puneet Sood and Vittorio Bertola for review. Bortzmeyer, Puneet Sood and Vittorio Bertola for review. Thanks to
Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York, Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York, Jon Reed,
Jon Reed, Lorenzo Colitti for comments at the mic. Thanks to Lorenzo Colitti for comments at the mic. Thanks to Loganaden
Loganaden Velvindron for useful updates to the text. Velvindron for useful updates to the text.
Sara Dickinson thanks the Open Technology Fund for a grant to support Sara Dickinson thanks the Open Technology Fund for a grant to support
the work on this document. the work on this document.
10. Contributors 10. Contributors
The below individuals contributed significantly to the document: The below individuals contributed significantly to the document:
John Dickinson John Dickinson
Sinodun Internet Technologies Sinodun Internet Technologies
skipping to change at page 23, line 42 skipping to change at page 23, line 42
Jim Hague Jim Hague
Sinodun Internet Technologies Sinodun Internet Technologies
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford OX4 4GA
United Kingdom United Kingdom
11. Changelog 11. Changelog
draft-ietf-dprive-bcp-op-12
o Change DROP to RPS throughout
draft-ietf-dprive-bcp-op-11 draft-ietf-dprive-bcp-op-11
o Improve text around use of normative language o Improve text around use of normative language
o Fix section 5.1.3.2 bullets o Fix section 5.1.3.2 bullets
o Improve text in 6.1.2. item 2. o Improve text in 6.1.2. item 2.
o Rework text of 6.1.2. item 5 and update example DROP o Rework text of 6.1.2. item 5 and update example DROP
o Various editorial improvements o Various editorial improvements
draft-ietf-dprive-bcp-op-10
o Remove direct references to draft-ietf-dprive-rfc7626-bis, instead o Remove direct references to draft-ietf-dprive-rfc7626-bis, instead
have one general reference RFC7626 have one general reference RFC7626
o Clarify that the DROP statement outline is non-normative and add o Clarify that the DROP statement outline is non-normative and add
some further qualifications about content some further qualifications about content
o Update wording on data sharing to remove explicit discussion of o Update wording on data sharing to remove explicit discussion of
consent consent
o Move table in section 5.2.3 to an appendix o Move table in section 5.2.3 to an appendix
skipping to change at page 39, line 42 skipping to change at page 39, line 42
performed a particular query. Large numbers of queries can be performed a particular query. Large numbers of queries can be
tracked in a memory-efficient way. As filter status is stored, this tracked in a memory-efficient way. As filter status is stored, this
approach cannot be used to regenerate traffic, and so cannot be used approach cannot be used to regenerate traffic, and so cannot be used
with tools used to process live traffic. with tools used to process live traffic.
Anonymized: Generalization. Anonymized: Generalization.
Appendix C. Current policy and privacy statements Appendix C. Current policy and privacy statements
A tabular comparison of policy and privacy statements from various A tabular comparison of policy and privacy statements from various
DNS Privacy service operators based loosely on the proposed DROP DNS Privacy service operators based loosely on the proposed RPS
structure can be found at [policy-comparison]. The analysis is based structure can be found at [policy-comparison]. The analysis is based
on the data available in December 2019. on the data available in December 2019.
We note that the existing set of policies vary widely in style, We note that the existing set of policies vary widely in style,
content and detail and it is not uncommon for the full text for a content and detail and it is not uncommon for the full text for a
given operator to equate to more than 10 pages of moderate font sized given operator to equate to more than 10 pages of moderate font sized
A4 text. It is a non-trivial task today for a user to extract a A4 text. It is a non-trivial task today for a user to extract a
meaningful overview of the different services on offer. meaningful overview of the different services on offer.
It is also noted that Mozilla have published a DoH resolver policy It is also noted that Mozilla have published a DoH resolver policy
[DoH-resolver-policy], which describes the minimum set of policy [DoH-resolver-policy], which describes the minimum set of policy
requirements that a party must satisfy to be considered as a requirements that a party must satisfy to be considered as a
potential partner for Mozilla's Trusted Recursive Resolver (TRR) potential partner for Mozilla's Trusted Recursive Resolver (TRR)
program. program.
Appendix D. Example DROP statement Appendix D. Example RPS
The following example DROP statement is very loosely based on some The following example RPS is very loosely based on some elements of
elements of published privacy statements for some public resolvers, published privacy statements for some public resolvers, with
with additional fields populated to illustrate the what the full additional fields populated to illustrate the what the full contents
contents of a DROP statement might look like. This should not be of an RPS might look like. This should not be interpreted as
interpreted as
o having been reviewed or approved by any operator in any way o having been reviewed or approved by any operator in any way
o having any legal standing or validity at all o having any legal standing or validity at all
o being complete or exhaustive o being complete or exhaustive
This is a purely hypothetical example of a DROP statement to outline This is a purely hypothetical example of an RPS to outline example
example contents - in this case for a public resolver operator contents - in this case for a public resolver operator providing a
providing a basic DNS Privacy service via one IP address and one DoH basic DNS Privacy service via one IP address and one DoH URI with
URI with security based filtering. It does aim to meet minimal security based filtering. It does aim to meet minimal compliance as
compliance as specified in Section 5. specified in Section 5.
D.1. Policy D.1. Policy
1. Treatment of IP addresses. Many nations classify IP addresses as 1. Treatment of IP addresses. Many nations classify IP addresses as
personal data, and we take a conservative approach in treating IP personal data, and we take a conservative approach in treating IP
addresses as personal data in all jurisdictions in which our addresses as personal data in all jurisdictions in which our
systems reside. systems reside.
2. Data collection and sharing. 2. Data collection and sharing.
 End of changes. 24 change blocks. 
53 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/