idnits 2.17.1 draft-dickinson-bcp-op-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7858], [RFC6841]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o User tracking: DNS privacy services SHOULD not track users. An exception may be malicious or anomalous use of the service. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Providing data to third-parties (sharing, selling or renting): Operators SHOULD not provide data to third-parties without explicit consent from users (simply using the resolution service itself does not constitute consent). -- The document date (March 5, 2018) is 2237 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 537 -- Looks like a reference, but probably isn't: '2' on line 539 == Outdated reference: A later version (-20) exists of draft-ietf-dnsop-session-signal-05 == Outdated reference: A later version (-06) exists of draft-ietf-dprive-padding-policy-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-dprive-padding-policy (ref. 'I-D.ietf-dprive-padding-policy') ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7626 (Obsoleted by RFC 9076) ** Obsolete normative reference: RFC 7816 (Obsoleted by RFC 9156) ** Downref: Normative reference to an Experimental RFC: RFC 8094 == Outdated reference: A later version (-15) exists of draft-ietf-dnsop-dns-tcp-requirements-01 -- Obsolete informational reference (is this intentional?): RFC 7706 (Obsoleted by RFC 8806) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive S. Dickinson 3 Internet-Draft Sinodun IT 4 Intended status: Best Current Practice R. van Rijswijk-Deij 5 Expires: September 6, 2018 SURFnet bv 6 A. Mankin 7 Salesforce 8 March 5, 2018 10 Recommendations for DNS Privacy Service Operators 11 draft-dickinson-bcp-op-00 13 Abstract 15 This document presents operational, policy and security 16 considerations for DNS operators who choose to offer DNS Privacy 17 services including, but not limited to, DNS-over-TLS [RFC7858]. 19 This document also presents a framework to assist writers of DNS 20 Privacy Policy and Practices Statements (analogous to DNS Security 21 Extensions (DNSSEC) Policies and DNSSEC Practice Statements described 22 in [RFC6841]). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 6, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Server capabilities to maximise DNS privacy . . . . . . . . . 5 61 3.1. General capabilities . . . . . . . . . . . . . . . . . . 5 62 3.2. Client query obfuscation . . . . . . . . . . . . . . . . 5 63 3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 6 64 3.4. Authentication of DNS privacy services . . . . . . . . . 6 65 3.4.1. Generation and publication of certificates . . . . . 6 66 3.4.2. Management of SPKI pins . . . . . . . . . . . . . . . 6 67 3.4.3. TLSA records . . . . . . . . . . . . . . . . . . . . 6 68 4. Operational management . . . . . . . . . . . . . . . . . . . 7 69 4.1. Limitations of using a pure TLS proxy . . . . . . . . . . 7 70 4.2. Anycast deployments . . . . . . . . . . . . . . . . . . . 7 71 5. Server data handling . . . . . . . . . . . . . . . . . . . . 7 72 5.1. Psuedo-anonymisation and de-identification methods . . . 8 73 5.1.1. ipcipher . . . . . . . . . . . . . . . . . . . . . . 8 74 5.1.2. Bloom filters . . . . . . . . . . . . . . . . . . . . 8 75 6. DNS privacy policy and practice statement . . . . . . . . . . 8 76 6.1. Current privacy statements . . . . . . . . . . . . . . . 8 77 6.2. Recommended contents of a DPPPS . . . . . . . . . . . . . 8 78 6.3. Enforcement/accountability . . . . . . . . . . . . . . . 9 79 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 80 8. Security considerations . . . . . . . . . . . . . . . . . . . 9 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 82 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 11.2. Informative References . . . . . . . . . . . . . . . . . 11 86 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 [NOTE: This document is submitted to the IETF for initial review and 92 for feedback on the best forum for future versions of this document.] 94 The Domain Name System (DNS) was not originally designed with strong 95 security or privacy mechanisms. [RFC7626] describes the privacy 96 issues associated with the use of the DNS by Internet users including 97 those related to un-encrypted DNS messages on the wire and DNS 'query 98 log' data maintained on DNS servers. 100 Two documents that provide ways to increase DNS privacy between DNS 101 clients and DNS servers are: 103 o Specification for DNS over Transport Layer Security (TLS) 104 [RFC7858], referred to here as simply 'DNS-over-TLS' 106 o DNS over Datagram Transport Layer Security (DTLS) [RFC8094], 107 referred to here simply as 'DNS-over-DTLS'. Note that this 108 document has the Category of Experimental. 110 Both documents are limited in scope to communications between stub 111 clients and recursive resolvers and the same scope is applied to this 112 document. Other documents that provide further specifications 113 related to DNS privacy include 114 [I-D.ietf-dprive-dtls-and-tls-profiles], [RFC7830] and 115 [I-D.ietf-dprive-padding-policy]. 117 Note that [I-D.ietf-dnsop-dns-tcp-requirements] discusses operational 118 requirements for DNS-over-TCP but does not provide specific guidance 119 on DNS privacy protocols. 121 This document includes operational guidance related to [RFC7858] and 122 [RFC8094]. 124 In recent years there has been an increase in the availability of 125 "open" resolvers. Operators of some open resolvers choose to enable 126 protocols which encrypt DNS on the wire to cater for users who are 127 privacy conscious. Whilst protocols that encrypt DNS messages on the 128 wire provide protection against certain attacks, the resolver 129 operator still has (in principle) full visibility of the query data 130 for each user and therefore a trust relationship exists. The ability 131 of the operator to provide a transparent, well documented, and secure 132 privacy service will likely serve as a major differentiating factor 133 for privacy conscious users. 135 More recently the global legislative landscape with regard to 136 personal data collection, retention, and psuedo-anonymisation has 137 seen significant activity with differing requirements active in 138 different jurisdictions. The impact of these changes on data 139 pertaining to the users of Internet Service Providers and 140 specifically DNS open resolvers is not fully understood at the time 141 of writing. It may be in certain cases that these requirement may 142 well conflict with the IETF's end-to-end encryption principles. 144 This document also attempts to outline options for data handling for 145 operators of DNS privacy services. 147 TODO/QUESTION: Discuss alternative (non-standard) schemes not covered 148 by this document e.g. DNSCrypt, IPsec, VPNs. For example, should 149 the data handling practices be recommended for any service that 150 encrypts DNS/makes claims about DNS data privacy or is that outside 151 the scope of this document? 153 This document also presents a framework to assist writers of DNS 154 Privacy Policy and Practice Statements (DPPPS). These are documents 155 an operator can publish outlining their operational practices and 156 commitments with regard to privacy providing a means for clients to 157 evaluate the privacy properties of a given DNS privacy service. In 158 particular, the framework identifies the elements that should be 159 considered in formulating a DPPPS. It does not, however, define a 160 particular Policy or Practice Statement, nor does it seek to provide 161 legal advice or recommendations as to the contents. 163 Community knowledge about operational practices can change quickly, 164 and experience shows that a Best Current Practice (BCP) document 165 about privacy and security is a point-in-time statement. Readers are 166 advised to seek out any errata or updates that apply to this 167 document. 169 2. Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC8174]. 175 o Privacy-enabling DNS server: A DNS server that implements DNS- 176 over-TLS [RFC7858] and may optionally implement DNS-over-DTLS 177 [RFC8094]. The server should also offer at least one of the 178 credentials described in Section 8 of 179 [I-D.ietf-dprive-dtls-and-tls-profiles] and implement the (D)TLS 180 profile described in Section 9 of 181 [I-D.ietf-dprive-dtls-and-tls-profiles]. 183 o DPPPS: DNS Privacy Policy and Practice Statement, see Section 6. 185 o DNS privacy service: The service that is offered via a privacy- 186 enabling DNS server and is documented either in an informal 187 statement of policy and practice with regard to users privacy or a 188 formal DPPPS. 190 3. Server capabilities to maximise DNS privacy 192 3.1. General capabilities 194 In addition to Sections 9 and 11.1 of 195 [I-D.ietf-dprive-dtls-and-tls-profiles] DNS privacy services SHOULD 196 offer the following capabilities/options: 198 o QNAME minimisation [RFC7816] 200 o Management of TLS connections to optimise performance for clients 201 using either 203 * [RFC7766] and EDNS(0) Keepalive [RFC7828] and/or 205 * DNS Stateful Operations [I-D.ietf-dnsop-session-signal] 207 o No requirement that clients must use TLS session resumption 208 [RFC5077] (or Domain Name System (DNS) Cookies [RFC7873]) 210 DNS privacy services MAY offer the following capabilities: 212 o DNS privacy service on both port 853 and 443 (to circumvent 213 blocking of port 853) 215 o A .onion [RFC7686] service endpoint 217 o Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the 218 number of queries to authoritative servers to increase privacy. 220 o Run a copy of the root zone on loopback [RFC7706] to avoid making 221 queries to the root servers that might leak information. 223 QUESTION: Should we say anything here about filtering responses or 224 DNSSEC validation e.g. operators SHOULD provide an unfiltered service 225 on an alternative IP address if the 'main' DNS privacy address 226 filters responses? Or simply just to say that the DNS privacy 227 service should not differ from the 'normal' DNS service in terms of 228 such options. 230 3.2. Client query obfuscation 232 Since queries from recursive resolvers to authoritative servers are 233 performed using cleartext (at the time of writing), resolver services 234 need to consider the extent to which they may be directly leaking 235 information about their client community via these upstream queries 236 and what they can do to mitigate this further. Note, that even when 237 all the relevant techniques described above are employed there may 238 still be attacks possible, e.g. [Pitfalls-of-DNS-Encryption]. For 239 example, a resolver with a very small community of users risks 240 exposing data in this way and MAY want to obfuscate this traffic by 241 mixing it with 'generated' traffic to make client characterisation 242 harder. 244 3.3. Availability 246 As a general model of trust between users and service providers DNS 247 privacy services should have high availability. Denying access to an 248 encrypted protocol for DNS queries forces the user to switch 249 providers, fallback to cleartext or accept no DNS service for the 250 outage. 252 3.4. Authentication of DNS privacy services 254 To enable users to select a 'Strict Privacy' usage profile 255 [I-D.ietf-dprive-dtls-and-tls-profiles] DNS privacy services should 256 provide credentials in the form of either X.509 certificates, SPKI 257 pinsets or TLSA records. This in effect commits the DNS privacy 258 service to a public identity users will trust. 260 Anecdotal evidence to date highlights this requirement as one of the 261 more challenging aspects of running a DNS privacy service as 262 management of such credentials is new to DNS operators. 264 3.4.1. Generation and publication of certificates 266 It is RECOMMENDED that operators: 268 o Choose a short, memorable authentication name for their service 270 o Automate the generation and publication of certificates 272 o Monitor certificates to prevent accidental expiration of 273 certificates 275 3.4.2. Management of SPKI pins 277 TODO 279 3.4.3. TLSA records 281 TODO 283 4. Operational management 285 4.1. Limitations of using a pure TLS proxy 287 Some operators may choose to implement DNS-over-TLS using a TLS proxy 288 (e.g. nginx [1] or haproxy [2]) in front of a DNS nameserver because 289 of proven robustness and capacity when handling large numbers of 290 client connections, load balancing capabilities and good tooling. 291 Currently, however, because such proxies typically have no specific 292 handling of DNS as a protocol over TLS or DTLS using them can 293 restrict traffic management at the proxy layer and at the DNS server. 294 For example, all traffic received by a nameserver behind such a proxy 295 will appear to originate from the proxy and DNS techniques such as 296 ACLs or RRL will be hard or impossible to implement in the 297 nameserver. 299 4.2. Anycast deployments 301 TODO: 303 5. Server data handling 305 The following are common activities for DNS service operators and in 306 all cases should be minimised or completely avoided if possible for 307 DNS privacy services. If data is retained it should be encrypted and 308 either aggregated, psuedo-anonymised or de-identified whenever 309 possible. 311 o Logging and Monitoring: Only that required to sustain operation of 312 the service and meet regulatory requirements. 314 o Data retention: Data SHOULD be retained for the shortest period 315 deemed operationally feasible. 317 o User tracking: DNS privacy services SHOULD not track users. An 318 exception may be malicious or anomalous use of the service. 320 o Providing data to third-parties (sharing, selling or renting): 321 Operators SHOULD not provide data to third-parties without 322 explicit consent from users (simply using the resolution service 323 itself does not constitute consent). 325 o Access to stored personal data: Access SHOULD be minimised to only 326 those personal who require access to perform operational duties. 328 5.1. Psuedo-anonymisation and de-identification methods 330 There is active discussion in the space of effective psuedo- 331 anonymisation of personal data in DNS query logs. To-date this has 332 focussed on psuedo-anonymisation of client IP addresses, however 333 there are as yet no standards for this that are unencumbered by 334 patents. This section briefly references some know methods in this 335 space at the time of writing. 337 5.1.1. ipcipher 339 [ipcipher-spec] is a psuedo-anonymisation technique which encrypts 340 IPv4 and IPv6 addresses such that any address encrypts to a valid 341 address. At the time of writing the specification is under review 342 and may be the subject of a future IETF draft. 344 5.1.2. Bloom filters 346 There is also on-going work in the area of using Bloom filters as a 347 privacy-enhancing technology for DNS monitoring [DNS-bloom-filter]. 348 The goal of this work is to allow operators to identify so-called 349 Indicators of Compromise (IOCs) originating from specific subnets 350 without storing information about, or be able to monitor the DNS 351 queries of an individual user. 353 6. DNS privacy policy and practice statement 355 6.1. Current privacy statements 357 TODO: Compare main elements of Google vs Quad9 vs OpenDNS policies 359 6.2. Recommended contents of a DPPPS 361 o Policy: This section should explain the policy for gathering and 362 disseminating information collected by the DNS privacy service. 364 * Specify clearly what data (including whether it is aggregated, 365 psuedo-anonymised or de-identified) is 367 * Collected and retained by the operator (and for how long) 369 * Shared with, sold or rented to third-parties 371 * Specify any exceptions to the above, for example malicious or 372 anomalous behaviour 374 * Declare any third-party affiliations or funding 375 * Whether user DNS data is correlated or combined with any other 376 personal information held by the operator 378 o Practice: This section should explain the current operational 379 practices of the service. 381 * Specify any temporary or permanent deviations from the policy 382 for operational reasons 384 * Provide specific details of which capabilities are provided on 385 which address and ports 387 * Specify the authentication name to be used (if any) 389 * Specify the SPKI pinsets to be used (if any) and policy for 390 rolling keys 392 * Provide a contact email address for the service 394 6.3. Enforcement/accountability 396 Transparency reports may help with building user trust that operators 397 adhere to their policies and practices. 399 Independent monitoring should be performed where possible of: 401 o ECS, QNAME minimisation, EDNS(0) padding, etc. 403 o Filtering 405 o Uptime 407 7. IANA considerations 409 None 411 8. Security considerations 413 TODO: e.g. New issues for DoS defence, server admin policies 415 9. Acknowledgements 417 Many thanks to John Dickinson for review of and input to the first 418 draft of this document. 420 Thanks to Benno Overeinder and John Todd for discussions on this 421 topic. 423 10. Changelog 425 draft-dickinson-dprive-bcp-op-00 427 o Initial commit 429 11. References 431 11.1. Normative References 433 [I-D.ietf-dnsop-session-signal] 434 Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 435 Mankin, A., and T. Pusateri, "DNS Stateful Operations", 436 draft-ietf-dnsop-session-signal-05 (work in progress), 437 January 2018. 439 [I-D.ietf-dprive-dtls-and-tls-profiles] 440 Dickinson, S., Gillmor, D., and T. Reddy, "Usage and 441 (D)TLS Profiles for DNS-over-(D)TLS", draft-ietf-dprive- 442 dtls-and-tls-profiles-11 (work in progress), September 443 2017. 445 [I-D.ietf-dprive-padding-policy] 446 Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf- 447 dprive-padding-policy-04 (work in progress), February 448 2018. 450 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 451 "Transport Layer Security (TLS) Session Resumption without 452 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 453 January 2008, . 455 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 456 DOI 10.17487/RFC7626, August 2015, . 459 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 460 D. Wessels, "DNS Transport over TCP - Implementation 461 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 462 . 464 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 465 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 466 . 468 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 469 edns-tcp-keepalive EDNS0 Option", RFC 7828, 470 DOI 10.17487/RFC7828, April 2016, . 473 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 474 DOI 10.17487/RFC7830, May 2016, . 477 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 478 and P. Hoffman, "Specification for DNS over Transport 479 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 480 2016, . 482 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 483 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 484 . 486 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 487 Transport Layer Security (DTLS)", RFC 8094, 488 DOI 10.17487/RFC8094, February 2017, . 491 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 492 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 493 May 2017, . 495 11.2. Informative References 497 [DNS-bloom-filter] 498 van Rijswijk-Deij, R., Bomhoff, M., and R. Dolmans, "Let a 499 Thousand Filters Bloom. DNS-Based Threat Monitoring That 500 Respects User Privacy", 2018, < https://tnc18.geant.org/ 501 getfile/3823>. 503 [I-D.ietf-dnsop-dns-tcp-requirements] 504 Kristoff, J. and D. Wessels, "DNS Transport over TCP - 505 Operational Requirements", draft-ietf-dnsop-dns-tcp- 506 requirements-01 (work in progress), November 2017. 508 [ipcipher-spec] 509 Hubert, B., "ipcipher: encrypting IP addresses", 2018, 510 . 512 [Pitfalls-of-DNS-Encryption] 513 Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS 514 Encryption", 2014, . 517 [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A 518 Framework for DNSSEC Policies and DNSSEC Practice 519 Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, 520 . 522 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 523 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 524 2015, . 526 [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root 527 Servers by Running One on Loopback", RFC 7706, 528 DOI 10.17487/RFC7706, November 2015, . 531 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 532 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 533 July 2017, . 535 11.3. URIs 537 [1] https://nginx.org/ 539 [2] https://www.haproxy.org/ 541 Authors' Addresses 543 Sara Dickinson 544 Sinodun IT 545 Magdalen Centre 546 Oxford Science Park 547 Oxford OX4 4GA 548 United Kingdom 550 Email: sara@sinodun.com 552 Roland M. van Rijswijk-Deij 553 SURFnet bv 554 PO Box 19035 555 Utrecht 3501 DA Utrecht 556 The Netherlands 558 Email: roland.vanrijswijk@surfnet.nl 559 Allison Mankin 560 Salesforce 562 Email: allison.mankin@gmail.com