draft-ietf-dprive-bcp-op-04.txt   draft-ietf-dprive-bcp-op-05.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: April 6, 2020 R. van Rijswijk-Deij Expires: May 3, 2020 R. van Rijswijk-Deij
NLnet Labs NLnet Labs
A. Mankin A. Mankin
Salesforce Salesforce
October 4, 2019 October 31, 2019
Recommendations for DNS Privacy Service Operators Recommendations for DNS Privacy Service Operators
draft-ietf-dprive-bcp-op-04 draft-ietf-dprive-bcp-op-05
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 framework to assist writers of a DNS This document also presents a framework to assist writers of a DNS
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 April 6, 2020. This Internet-Draft will expire on May 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Privacy related documents . . . . . . . . . . . . . . . . . . 5 3. Privacy related documents . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Recommendations for DNS privacy services . . . . . . . . . . 6 5. Recommendations for DNS privacy services . . . . . . . . . . 6
5.1. On the wire between client and server . . . . . . . . . . 7 5.1. On the wire between client and server . . . . . . . . . . 7
5.1.1. Transport recommendations . . . . . . . . . . . . . . 7 5.1.1. Transport recommendations . . . . . . . . . . . . . . 7
5.1.2. Authentication of DNS privacy services . . . . . . . 8 5.1.2. Authentication of DNS privacy services . . . . . . . 8
5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9 5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9
5.1.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.5. Availability . . . . . . . . . . . . . . . . . . . . 12 5.1.5. Availability . . . . . . . . . . . . . . . . . . . . 11
5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12 5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12
5.1.7. Impact on DNS Privacy Service Operators . . . . . . . 12 5.1.7. Impact on DNS Privacy Service Operators . . . . . . . 12
5.1.8. Limitations of using a pure TLS proxy . . . . . . . . 13 5.1.8. Limitations of using a pure TLS proxy . . . . . . . . 13
5.2. Data at rest on the server . . . . . . . . . . . . . . . 14 5.2. Data at rest on the server . . . . . . . . . . . . . . . 13
5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 13
5.2.2. Data minimization of network traffic . . . . . . . . 15 5.2.2. Data minimization of network traffic . . . . . . . . 14
5.2.3. IP address pseudonymization and anonymization methods 16 5.2.3. IP address pseudonymization and anonymization methods 15
5.2.4. Pseudonymization, anonymization or discarding of 5.2.4. Pseudonymization, anonymization or discarding of
other correlation data . . . . . . . . . . . . . . . 17 other correlation data . . . . . . . . . . . . . . . 17
5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 18 5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17
5.3. Data sent onwards from the server . . . . . . . . . . . . 18 5.3. Data sent onwards from the server . . . . . . . . . . . . 18
5.3.1. Protocol recommendations . . . . . . . . . . . . . . 18 5.3.1. Protocol recommendations . . . . . . . . . . . . . . 18
5.3.2. Client query obfuscation . . . . . . . . . . . . . . 19 5.3.2. Client query obfuscation . . . . . . . . . . . . . . 19
5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 20 5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19
6. DNS Recursive Operator Privacy (DROP) statement . . . . . . . 21 6. DNS Recursive Operator Privacy (DROP) statement . . . . . . . 20
6.1. Recommended contents of a DROP statement . . . . . . . . 21 6.1. Recommended contents of a DROP statement . . . . . . . . 20
6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 21 6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20
6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 22 6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Current policy and privacy statements . . . . . . . . . . 23 6.2. Current policy and privacy statements . . . . . . . . . . 22
6.3. Enforcement/accountability . . . . . . . . . . . . . . . 24 6.3. Enforcement/accountability . . . . . . . . . . . . . . . 23
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security considerations . . . . . . . . . . . . . . . . . . . 24 8. Security considerations . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 28
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 31
A.1. Potential increases in DNS privacy . . . . . . . . . . . 32 A.1. Potential increases in DNS privacy . . . . . . . . . . . 31
A.2. Potential decreases in DNS privacy . . . . . . . . . . . 32 A.2. Potential decreases in DNS privacy . . . . . . . . . . . 31
A.3. Related operational documents . . . . . . . . . . . . . . 33 A.3. Related operational documents . . . . . . . . . . . . . . 32
Appendix B. IP address techniques . . . . . . . . . . . . . . . 33 Appendix B. IP address techniques . . . . . . . . . . . . . . . 32
B.1. Google Analytics non-prefix filtering . . . . . . . . . . 34 B.1. Google Analytics non-prefix filtering . . . . . . . . . . 33
B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 34 B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 33
B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 35 B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 34
B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 35 B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 34
B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 35 B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 34
B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 36 B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 35
B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 36 B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 35
Appendix C. Example DROP statement . . . . . . . . . . . . . . . 36 Appendix C. Example DROP statement . . . . . . . . . . . . . . . 35
C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 37 C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 36
C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 39 C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
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
place in recent years which aim to increase the privacy of the DNS place in recent years which aim to increase the privacy of the DNS
system and these are now seeing some deployment. This latest system and these are now seeing some deployment. This latest
evolution of the DNS presents new challenges to operators and this evolution of the DNS presents new challenges to operators and this
skipping to change at page 8, line 38 skipping to change at page 8, line 38
When using DNS-over-TLS clients that select a 'Strict Privacy' usage When using DNS-over-TLS clients that select a 'Strict Privacy' usage
profile [RFC8310] (to mitigate the threat of active attack on the profile [RFC8310] (to mitigate the threat of active attack on the
client) require the ability to authenticate the DNS server. To client) require the ability to authenticate the DNS server. To
enable this, DNS privacy services that offer DNS-over-TLS should enable this, DNS privacy services that offer DNS-over-TLS should
provide credentials in the form of either X.509 certificates provide credentials in the form of either X.509 certificates
[RFC5280] or SPKI pin sets [RFC8310]. [RFC5280] or SPKI pin sets [RFC8310].
When offering DoH [RFC8484], HTTPS requires authentication of the When offering DoH [RFC8484], HTTPS requires authentication of the
server as part of the protocol. server as part of the protocol.
Optimizations:
DNS privacy services can also consider the following capabilities/
options:
o As recommended in [RFC8310] providing DANE TLSA records for the
nameserver
* In particular, the service could provide TLSA records such that
authenticating solely via the PKIX infrastructure can be
avoided.
5.1.2.1. Certificate management 5.1.2.1. Certificate management
Anecdotal evidence to date highlights the management of certificates Anecdotal evidence to date highlights the management of certificates
as one of the more challenging aspects for operators of traditional as one of the more challenging aspects for operators of traditional
DNS resolvers that choose to additionally provide a DNS privacy DNS resolvers that choose to additionally provide a DNS privacy
service as management of such credentials is new to those DNS service as management of such credentials is new to those DNS
operators. operators.
It is noted that SPKI pin set management is described in [RFC7858] It is noted that SPKI pin set management is described in [RFC7858]
but that key pinning mechanisms in general have fallen out of favor but that key pinning mechanisms in general have fallen out of favor
skipping to change at page 9, line 34 skipping to change at page 9, line 19
Mitigations: Mitigations:
It is recommended that operators: It is recommended that operators:
o Follow the guidance in Section 6.5 of [RFC7525] with regards to o Follow the guidance in Section 6.5 of [RFC7525] with regards to
certificate revocation certificate revocation
o Choose a short, memorable authentication name for the service o Choose a short, memorable authentication name for the service
o Automate the generation and publication of certificates o Automate the generation, publication and renewal of certificates.
For example, ACME [RFC8555] provides a mechanism to actively
manage certificates through automation and has been implemented by
a number of certificate authorities.
o Monitor certificates to prevent accidental expiration of o Monitor certificates to prevent accidental expiration of
certificates certificates
5.1.3. Protocol recommendations 5.1.3. Protocol recommendations
5.1.3.1. DNS-over-TLS 5.1.3.1. DNS-over-TLS
DNS Privacy Threats: DNS Privacy Threats:
skipping to change at page 10, line 14 skipping to change at page 10, line 4
Mitigations: Mitigations:
In the case of DNS-over-TLS, TLS profiles from Section 9 and the In the case of DNS-over-TLS, TLS profiles from Section 9 and the
Countermeasures to DNS Traffic Analysis from section 11.1 of Countermeasures to DNS Traffic Analysis from section 11.1 of
[RFC8310] provide strong mitigations. This includes but is not [RFC8310] provide strong mitigations. This includes but is not
limited to: limited to:
o Adhering to [RFC7525] o Adhering to [RFC7525]
o Implementing only (D)TLS 1.2 or later as specified in [RFC8310] o Implementing only (D)TLS 1.2 or later as specified in [RFC8310]
o Implementing EDNS(0) Padding [RFC7830] using the guidelines in o Implementing EDNS(0) Padding [RFC7830] using the guidelines in
[RFC8467] or a successor specification. [RFC8467] or a successor specification.
o Clients should not be required to use TLS session resumption o Servers should not degrade in any way the query service level
[RFC5077] with TLS 1.2 or Domain Name System (DNS) Cookies provided to clients that do not use any form of session resumption
mechanism, such as TLS session resumption [RFC5077] with TLS 1.2,
section 2.2 of RFC8446, or Domain Name System (DNS) Cookies
[RFC7873]. [RFC7873].
o A DNS-over-TLS privacy service on both port 853 and 443. This o A DNS-over-TLS privacy service on both port 853 and 443. This
practice may not be possible if e.g. the operator deploys DoH on practice may not be possible if e.g. the operator deploys DoH on
the same IP address. the same IP address.
Optimizations: Optimizations:
o Concurrent processing of pipelined queries, returning responses as o Concurrent processing of pipelined queries, returning responses as
soon as available, potentially out of order as specified in soon as available, potentially out of order as specified in
[RFC7766]. This is often called 'OOOR' - out-of-order responses. [RFC7766]. This is often called 'OOOR' - out-of-order responses.
(Providing processing performance similar to HTTP multiplexing) (Providing processing performance similar to HTTP multiplexing)
o Management of TLS connections to optimize performance for clients o Management of TLS connections to optimize performance for clients
using either using either
* [RFC7766] and EDNS(0) Keepalive [RFC7828] and/or * [RFC7766] and EDNS(0) Keepalive [RFC7828] and/or
* DNS Stateful Operations [RFC8490] * DNS Stateful Operations [RFC8490]
Additional options that providers may consider:
o Offer a .onion [RFC7686] service endpoint
5.1.3.2. DoH 5.1.3.2. DoH
DNS Privacy Threats: DNS Privacy Threats:
o Known attacks on TLS such as those described in [RFC7457] o Known attacks on TLS such as those described in [RFC7457]
o Traffic analysis, for example: DNS Privacy not so private: the o Traffic analysis, for example: DNS Privacy not so private: the
traffic analysis perspective [1] traffic analysis perspective [1]
o Potential for client tracking via transport identifiers o Potential for client tracking via transport identifiers
skipping to change at page 17, line 51 skipping to change at page 17, line 13
ensuring packets are captured by the target and the attacker can send ensuring packets are captured by the target and the attacker can send
forged traffic with arbitrary source and destination addresses to forged traffic with arbitrary source and destination addresses to
that target, any format-preserving pseudonymization is vulnerable to that target, any format-preserving pseudonymization is vulnerable to
an attack along the lines of a cryptographic chosen plaintext attack. an attack along the lines of a cryptographic chosen plaintext attack.
5.2.4. Pseudonymization, anonymization or discarding of other 5.2.4. Pseudonymization, anonymization or discarding of other
correlation data correlation data
DNS Privacy Threats: DNS Privacy Threats:
o IP TTL/Hoplimit can be used to fingerprint client OS o Fingerprinting of the client OS via various means including: IP
o TLS version/Cipher suite combinations can be used to fingerprint TTL/Hoplimit, TCP parameters (e.g. window size, ECN support,
the client application or TLS library SACK), OS specific DNS query patterns (e.g. for network
connectivity, captive portal detection or OS specific updates).
o Tracking of TCP sessions o Fingerprinting of the client application or TLS library by e.g.
TLS version/Cipher suite combinations or other connection
parameters.
o Tracking of TLS sessions and session resumption mechanisms o Correlation of queries on multiple TCP session originating from
the same IP address
o Correlating of queries on multiple TLS sessions originating from
the same client, including via session resumption mechanisms
o Resolvers _might_ receive client identifiers e.g. MAC addresses o Resolvers _might_ receive client identifiers e.g. MAC addresses
in EDNS(0) options - some CPE devices are known to add them. in EDNS(0) options - some CPE devices are known to add them.
o HTTP headers o HTTP headers (e.g., User-Agent, Accept, Accept-Encoding)
Mitigations: Mitigations:
o Data minimization or discarding of such correlation data. o Data minimization or discarding of such correlation data.
5.2.5. Cache snooping 5.2.5. Cache snooping
[RFC6973] Threats: [RFC6973] Threats:
o Surveillance: o Surveillance:
skipping to change at page 20, line 44 skipping to change at page 20, line 15
o Contravention of legal requirements not to process user data o Contravention of legal requirements not to process user data
Mitigations: Mitigations:
Operators should not provide identifiable data to third-parties Operators should not provide identifiable data to third-parties
without explicit consent from clients (we take the stance here that without explicit consent from clients (we take the stance here that
simply using the resolution service itself does not constitute simply using the resolution service itself does not constitute
consent). consent).
Even when consent is granted operators should employ data
minimization techniques such as those described in Section 5.2.1 if
data is shared with third-parties.
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 SURFnet's policy [11] on but also the wider Internet community. See SURFnet's policy [11] on
data sharing for research as an example. data sharing for research as an example.
6. DNS Recursive Operator Privacy (DROP) statement 6. DNS Recursive Operator Privacy (DROP) statement
The following section outlines the recommended contents of a DROP The following section outlines the recommended contents of a DROP
skipping to change at page 22, line 31 skipping to change at page 21, line 48
service. service.
1. Deviations. Specify any temporary or permanent deviations from 1. Deviations. Specify any temporary or permanent deviations from
the policy for operational reasons. the policy for operational reasons.
2. Client facing capabilities. With reference to section Section 5 2. Client facing capabilities. With reference to section Section 5
provide specific details of which capabilities are provided on provide specific details of which capabilities are provided on
which client facing addresses and ports: which client facing addresses and ports:
1. For DoT, specify the authentication name to be used (if any) 1. For DoT, specify the authentication name to be used (if any)
and if TLSA records are published (including options used in
the TLSA records)
2. For DoT, specify the SPKI pin sets to be used (if any) and 2. For DoT, specify the SPKI pin sets to be used (if any) and
policy for rolling keys policy for rolling keys
3. Upstream capabilities. With reference to section Section 5.3 3. Upstream capabilities. With reference to section Section 5.3
provide specific details of which capabilities are provided provide specific details of which capabilities are provided
upstream for data sent to authoritative servers. upstream for data sent to authoritative servers.
4. Support. Provide contact/support information for the service. 4. Support. Provide contact/support information for the service.
skipping to change at page 23, line 23 skipping to change at page 22, line 37
handling the DNS requests and the data are located (if the handling the DNS requests and the data are located (if the
operator applies a geolocation policy so that requests from operator applies a geolocation policy so that requests from
certain countries are only served by certain servers, this certain countries are only served by certain servers, this
should be specified as well). should be specified as well).
4. Specify whether the operator has any agreement in place with 4. Specify whether the operator has any agreement in place with
law enforcement agencies, or other public and private parties law enforcement agencies, or other public and private parties
dealing with security and intelligence, to give them access dealing with security and intelligence, to give them access
to the servers and/or to the data. to the servers and/or to the data.
6. Consent. For any activity which is documented in this statement
as 'requiring consent' before being performed, describe the full
process of what you as an operator consider 'obtaining consent',
distinguishing clearly between any implicit and explicit consent
models. Additionally, state if these processes are considered by
you the operator to conform to any relevant legislation (this may
prove relevant in the context of e.g. the GDPR as it relates to
consent).
6.2. Current policy and privacy statements 6.2. Current policy and privacy statements
A tabular comparison of existing policy and privacy statements from A tabular comparison of existing policy and privacy statements from
various DNS Privacy service operators based loosely on the proposed various DNS Privacy service operators based loosely on the proposed
DROP structure can be found on dnsprivacy.org [12]. DROP structure can be found on dnsprivacy.org [12].
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
skipping to change at page 25, line 25 skipping to change at page 24, line 25
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-05
o Remove some text on consent:
* Paragraph 2 in section 5.3.3
* Item 6 in the DROP Practice statement (and example)
o Remove .onion and TLSA options
o Include ACME as a reference for certificate management
o Update text on session resumption usage
o Update section 5.2.4 on client fingerprinting
draft-ietf-dprive-bcp-op-04 draft-ietf-dprive-bcp-op-04
o Change DPPPS to DROP (DNS Recursive Operator Privacy) statement o Change DPPPS to DROP (DNS Recursive Operator Privacy) statement
o Update structure of DROP slightly o Update structure of DROP slightly
o Add example DROP statement o Add example DROP statement
o Add text about restricting access to full logs o Add text about restricting access to full logs
skipping to change at page 29, line 42 skipping to change at page 29, line 10
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization
Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,
<https://www.rfc-editor.org/info/rfc6235>. <https://www.rfc-editor.org/info/rfc6235>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/info/rfc7457>. February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
2015, <https://www.rfc-editor.org/info/rfc7686>.
[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
Servers by Running One on Loopback", RFC 7706, Servers by Running One on Loopback", RFC 7706,
DOI 10.17487/RFC7706, November 2015, <https://www.rfc- DOI 10.17487/RFC7706, November 2015, <https://www.rfc-
editor.org/info/rfc7706>. editor.org/info/rfc7706>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, <https://www.rfc- DOI 10.17487/RFC8094, February 2017, <https://www.rfc-
editor.org/info/rfc8094>. editor.org/info/rfc8094>.
skipping to change at page 30, line 23 skipping to change at page 29, line 33
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations", Lemon, T., and T. Pusateri, "DNS Stateful Operations",
RFC 8490, DOI 10.17487/RFC8490, March 2019, RFC 8490, DOI 10.17487/RFC8490, March 2019,
<https://www.rfc-editor.org/info/rfc8490>. <https://www.rfc-editor.org/info/rfc8490>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T., [RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T.,
and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS
Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September
2019, <https://www.rfc-editor.org/info/rfc8618>. 2019, <https://www.rfc-editor.org/info/rfc8618>.
12.3. URIs 12.3. URIs
[1] https://petsymposium.org/2018/files/hotpets/4-siby.pdf [1] https://petsymposium.org/2018/files/hotpets/4-siby.pdf
[2] http://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/ [2] http://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/
skipping to change at page 39, line 48 skipping to change at page 39, line 4
form (insert link) if you believe we are blocking a form (insert link) if you believe we are blocking a
domain in error. domain in error.
C.2. Practice C.2. Practice
1. Deviations from Policy. None currently in place. 1. Deviations from Policy. None currently in place.
2. Client facing capabilities. 2. Client facing capabilities.
1. We offer UDP and TCP DNS on port 53 on (insert IP address) 1. We offer UDP and TCP DNS on port 53 on (insert IP address)
2. We offer DNS-over-TLS as specified in RFC7858 on (insert IP 2. We offer DNS-over-TLS as specified in RFC7858 on (insert IP
address). It is available on port 853 and port 443. We also address). It is available on port 853 and port 443. We also
implement RFC7766. implement RFC7766.
1. The DoT authentication name used is (insert domain name). 1. The DoT authentication name used is (insert domain name).
No TLSA records are available for this domain name.
2. We do not publish SPKI pin sets. 2. We do not publish SPKI pin sets.
3. We offer DNS-over-HTTPS as specified in RFC8484 on (insert 3. We offer DNS-over-HTTPS as specified in RFC8484 on (insert
URI template). Both POST and GET are supported. URI template). Both POST and GET are supported.
4. Both services offer TLS 1.2 and TLS 1.3. 4. Both services offer TLS 1.2 and TLS 1.3.
5. Both services pad DNS responses according to RFC8467. 5. Both services pad DNS responses according to RFC8467.
skipping to change at page 40, line 49 skipping to change at page 40, line 5
3. We operate servers in the following countries (insert list). 3. We operate servers in the following countries (insert list).
4. We have no agreements in place with law enforcement agencies 4. We have no agreements in place with law enforcement agencies
to give them access to the data. Apart from as stated in the to give them access to the data. Apart from as stated in the
Policy section of this document with regard to cyber threat Policy section of this document with regard to cyber threat
intelligence, we have no agreements in place with other intelligence, we have no agreements in place with other
public and private parties dealing with security and public and private parties dealing with security and
intelligence, to give them access to the servers and/or to intelligence, to give them access to the servers and/or to
the data. the data.
6. Consent. As described, we do not intentionally share, sell, or
rent individual personal information associated with the
requestor with anyone without your consent. In order to provide
consent you must have a user account for our service - this can
be set up via our support page (insert link). We may contact
existing users with accounts to enquire if you would be willing
to provide consent for specific situations. Users can then
provide explicit consent by choosing to enable certain account
options which are disabled by default.
Authors' Addresses Authors' Addresses
Sara Dickinson Sara Dickinson
Sinodun IT Sinodun IT
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford OX4 4GA
United Kingdom United Kingdom
Email: sara@sinodun.com Email: sara@sinodun.com
 End of changes. 28 change blocks. 
97 lines changed or deleted 82 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/