idnits 2.17.1 draft-ietf-dprive-phase2-requirements-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 : ---------------------------------------------------------------------------- No issues found here. 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 'MUST not' in this paragraph: 10. For the secure transport, TLS 1.3 (or later versions) MUST be supported and downgrades from TLS 1.3 to prior versions MUST not occur. -- The document date (December 14, 2019) is 1593 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 422 -- Looks like a reference, but probably isn't: '2' on line 424 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DPRIVE J. Livingood 3 Internet-Draft Comcast 4 Intended status: Informational A. Mayrhofer 5 Expires: June 16, 2020 nic.at GmbH 6 B. Overeinder 7 NLnet Labs 8 December 14, 2019 10 DNS Privacy Requirements for Exchanges between Recursive Resolvers and 11 Authoritative Servers 12 draft-ietf-dprive-phase2-requirements-00 14 Abstract 16 This document provides requirements for adding confidentiality to DNS 17 exchanges between recursive resolvers and authoritative servers. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 16, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction & Scope . . . . . . . . . . . . . . . . . . . . 2 54 2. Document Work Via GitHub . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Threat Model and Problem Statement . . . . . . . . . . . . . 3 57 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5.1. Mandatory Requirements . . . . . . . . . . . . . . . . . 4 59 5.2. Optional Requirements . . . . . . . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 9. APPENDIX: Perspectives and Use Cases . . . . . . . . . . . . 5 64 9.1. The User Perspective and Use Cases . . . . . . . . . . . 6 65 9.2. The Operator Perspective and Use Cases . . . . . . . . . 6 66 9.3. The Implementor / Software Vendor Perspective and Use 67 Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 10.2. Informative References . . . . . . . . . . . . . . . . . 9 71 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction & Scope 77 The 2018 approved charter of the IETF DPRIVE Working Group [1] 78 contains milestones related to confidentiality aspects of DNS 79 transactions between the iterative resolver and authoritative name 80 servers. 82 This is also reflected in the DPRIVE milestones [2], which (as of 83 October 2019) contains two relevant milestones: 85 Develop requirements for adding confidentiality to DNS exchanges 86 between recursive resolvers and authoritative servers (unpublished 87 document). 89 Investigate potential solutions for adding confidentiality to DNS 90 exchanges involving authoritative servers (Experimental). 92 This document intends to cover the first milestone for defining 93 requirements for adding confidentiality to DNS exchanges between 94 recursive resolvers and authoritative servers. This may in turn lead 95 to progress in investigating, developing and standardizing potential 96 experimental methods of meeting those requirements. 98 The motivation for this work is to extend the confidentiality methods 99 used between a user's stub resolver and a recursive resolver to the 100 recursive queries sent by recursive resolvers in response to a DNS 101 lookup (when a cache miss occurs and the server must perform 102 recursion to obtain a response to the query). A recursive resolver 103 will send queries to root servers, to Top Level Domain (TLD) servers, 104 to authoritative second level domain servers and potentially to other 105 authoritative DNS servers and each of these query/response 106 transactions presents an opportunity to extend the confidentiality of 107 user DNS queries. 109 2. Document Work Via GitHub 111 The authors are working on this document via GitHub at 112 https://github.com/alex-nicat/ietf-dprive-phase2-requirements. 113 Feedback via pull requests and issues are invited there. 115 3. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 This document also makes use of DNS Terminology defined in [RFC8499] 125 4. Threat Model and Problem Statement 127 Currently, protocols such as DoT provide encryption between the 128 user's stub resolver and a recursive resolver. This potentially 129 provides (1) protection from observation of end user DNS queries and 130 responses, (2) protection from on-the-wire modification DNS queries 131 or responses (including potentially forcing a downgrade to an 132 unencrypted communication). Of course, observation and modification 133 are still possible when performed by the recursive resolver, which 134 decrypts queries, serves a response from cache or performs recursion 135 to obtain a response (or synthesizes a response), and then encrypts 136 the response and sends it back to the user's stub resolver. 138 But observation and modification threats still exist when a recursive 139 resolver must perform DNS recursion, from the root to TLD to 140 authoritative servers. This document specifies requirements for 141 filling those gaps. 143 5. Requirements 145 The requirements of different interested stakeholders are outlined 146 below. 148 5.1. Mandatory Requirements 150 1. Each implementing party should be able to independently take 151 incremental steps to meet requirements without the need for 152 close coordination (e.g. loosely coupled) 154 2. Use a secure transport protocol between a recursive resolver and 155 authoritative servers 157 3. Use a secure transport protocol between a recursive resolver and 158 TLD servers 160 4. Use a secure transport protocol between a recursive resolver and 161 the root servers 163 5. The secure transport MUST only be established when referential 164 integrity can be verified, MUST NOT have circular dependencies, 165 and MUST be easily analyzed for diagnostic purposes. 167 6. Use a secure transport protocol or other DNS privacy protections 168 in a manner that enables operators to perform appropriate 169 performance and security monitoring, conduct relevant research, 170 etc. 172 7. The authoritative domain owner or their administrator MUST have 173 the option to specify their secure transport preferences (e.g. 174 what specific protocols are supported). This SHALL include a 175 method to publish a list of secure transport protocols (e.g. 176 DoH, DoT and other future protocols not yet developed). In 177 addition this SHALL include whether a secure transport protocol 178 MUST always be used (non-downgradable) or whether a secure 179 transport protocol MAY be used on an opportunistic (not strict) 180 basis. 182 8. The authoritative domain owner or their administrator MUST have 183 the option to vary their preferences on an authoritative 184 nameserver to nameserver basis, due to the fact that 185 administration of a particular DNS zone may be delegated to 186 multiple parties (such as several CDNs), each of which may have 187 different technical capabilities. 189 9. The specification of secure transport preferences MUST be 190 performed using the DNS and MUST NOT depend on non-DNS 191 protocols. 193 10. For the secure transport, TLS 1.3 (or later versions) MUST be 194 supported and downgrades from TLS 1.3 to prior versions MUST not 195 occur. 197 5.2. Optional Requirements 199 1. QNAME minimisation SHOULD be implemented in all steps of 200 recursion 202 2. DNSSEC validation SHOULD be performed 204 3. If an authoritative domain owner or their administrator indicates 205 that (1) multiple secure transport protocols are available or 206 that (2) a secure transport and insecure transport are available, 207 then per the recommendations in [RFC8305] (aka Happy Eyeballs) a 208 recursive server SHOULD initiate concurrent connections to 209 available protocols. Consistent with Section 2 of [RFC8305] this 210 would be: (1) Initiation of asynchronous DNS queries to determine 211 what transport protocols are supported, (2) Sorting of resolved 212 destination transport protocols, (3) Initiation of asynchronous 213 connection attempts, and (4) Establishment of one connection, 214 which cancels all other attempts. 216 6. Security Considerations 218 This entire document concerns the security of DNS traffic, so a 219 specific section on security is superfluous. 221 7. IANA Considerations 223 This document has no actions for IANA. 225 8. Changelog 227 Version 00: Updated prior individual draft following IETF-106 228 feedback 230 9. APPENDIX: Perspectives and Use Cases 232 The DNS resolving process involves several entities. These entities 233 have different interests/requirements, and hence it does make sense 234 to examine the interests of those entities separately - though in 235 many cases their interests are aligned. Four different entities can 236 be identified, and their interests are described in the following 237 sections: 239 o Users 241 o Operators 243 o Implementors / Software Developers 245 o Researchers 247 9.1. The User Perspective and Use Cases 249 The privacy and confidentiality of Users (that is, users as in 250 clients of recursive resolvers, which in turn forward/resolve the 251 user's DNS requests by contacting authoritative servers) can be 252 improved in several ways. We call this "minimisation of exposure", 253 and there are currently three ways to reduce that exposure: 255 o Qname minimisation [RFC7816], reducing the amount of information 256 which is absolutely necessary to resolve a query 258 o Aggressive NSEC/local auth cache [RFC8198], reducing the amount of 259 outgoing queries in the first place 261 o Encryption, removing exposure of information while in transit 263 As recursors typically forwards queries received from the user to 264 authoritative servers. This creates a transitive trust between the 265 user and the recursor, as well as the authoritative server, since 266 information created by the user is exposed to the authoritative 267 server. However, the user has never a chance to identify which data 268 was exposed to which authoritative party (via which path). 270 Also, Users would want to be informed about the status of the 271 connections which were made on their behalf, which adds a fourth 272 point 274 Encryption/privacy status signaling 276 *TODO*: Actual requirements - what do users "want"? Start below: 278 9.2. The Operator Perspective and Use Cases 280 Operators of authoritative services have to provide stable and fast 281 DNS services, and interact with a wide range of clients, not all of 282 them authoritative servers. The operator side actually consists of 283 two sides: 285 o The "upstream" facing side of recursive resolvers 287 o The "downstream" side of authoritative servers 289 Those two sides are typically operated by different entities, but 290 many entities operate "both sides". Even though that is discouraged 291 (*TODO* source), the two sides might even be operated on the same 292 nameserver. 294 o Maybe different technical perspectives for operators 296 * Intelligence (sharing information) 298 * SLD popularity for marketing 300 o Focus initially on Second Level Domains (SLDs) initially 302 * Is there a difference for TLDs vs. SLDs from a "protocol" 303 perspective? 305 o Monitoring and aggregated data analysis 307 o Signaling provisioning information 309 * New record type for finding authoritative server key and 310 authentication? Use SRV? (Being able to use different servers 311 for serving up DNS-over-{TCP,UDP} vs DNS-over-TLS responses may 312 be valuable. 314 * Signal secure transport details (DNS-over-TLS, DNS-over-QUIC, 315 EncryptedSNI, connectionless, etc.), perhaps in an extensible 316 manner? Minimize RTTs and reduce need for trials. 318 * Large provider use cases where the NS names are out of 319 bailiwick for the zone (e.g. small number of distinct NS 320 records serving 100k+ zones) 322 o EDNS client subnet (JL: Not sure ECS crosses the cost/benefit 323 threshold to be included as a requirement and many CDNs that run 324 auth servers will likely say ECS is quite operationally important) 326 o Decide between TLS and connectionless (such as COSE-based 327 messages) 329 o Costs of TLS connection vs. connectionless 331 * Technical solution, e.g. encryption of the DNS query, shouldn't 332 enable an attack vector for DDoS or resource exhaustion. For 333 example, only if the client uses DNS-over-TLS, the upstream 334 query to the authoritative will be over DNS-over-TLS also. If 335 the client uses UDP, the resolver won't invest resources in 336 DNS-over-TLS to prevent a potential resource exhaustion attack. 338 * Reuse connection state (if any) and examine resumption 339 considerations 341 * Minimize server-side state (eg, with session tickets) 343 * Need empirical studies on capacity, traffic, attack vectors 345 * Evaluate impact on architecture and footprint expansion 347 * Analyze optimal persistent connection time/time-out 349 * Analyze optimal number of persistent connections recursive 350 resolvers should maintain 352 * Consider operational concerns with respect to capabilities 353 signaling 355 * Develop a profile that has operational advantages for operators 357 *TODO*: Actual requirements - what do operators "want"? 359 9.3. The Implementor / Software Vendor Perspective and Use Cases 361 Implementer requirements follows requirements from user and operator 362 perspectives: 364 o Non-functional requirements, e.g. diversity of implementations 366 o Horizontal vs. vertical scaling, for example similar to http 367 servers 369 o Use of DANE [RFC6698] for authentication: strict vs. opportunistic 371 o Incremental deployment 373 o Cache reuse vs. downgrade? Does the cache need to be partitioned? 374 When can an in-cache answer retrieved via cleartext be served 375 encrypted to a recursive query? 377 o (Use of TCP fast open) - but this might be a requirement for the 378 actual encryption protocol 380 *TODO*: Actual requirements of implementors - essentially, they 381 follow what Operators need? 383 10. References 385 10.1. Normative References 387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 388 Requirement Levels", BCP 14, RFC 2119, 389 DOI 10.17487/RFC2119, March 1997, 390 . 392 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 393 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 394 May 2017, . 396 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 397 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 398 January 2019, . 400 10.2. Informative References 402 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 403 of Named Entities (DANE) Transport Layer Security (TLS) 404 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 405 2012, . 407 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 408 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 409 . 411 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 412 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 413 July 2017, . 415 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 416 Better Connectivity Using Concurrency", RFC 8305, 417 DOI 10.17487/RFC8305, December 2017, 418 . 420 10.3. URIs 422 [1] https://datatracker.ietf.org/doc/charter-ietf-dprive/ 424 [2] https://datatracker.ietf.org/wg/dprive/about/ 426 Acknowledgments 428 TODO 430 Authors' Addresses 432 Jason Livingood 433 Comcast 435 Email: Jason_Livingood@comcast.com 437 Alexander Mayrhofer 438 nic.at GmbH 440 Email: alex.mayrhofer.ietf@gmail.com 442 Benno Overeinder 443 NLnet Labs 445 Email: benno@NLnetLabs.nl