idnits 2.17.1 draft-box-add-requirements-01.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 -- The document date (2 November 2020) is 1269 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD C. Box 3 Internet-Draft BT 4 Intended status: Informational T. Pauly 5 Expires: 6 May 2021 Apple 6 C.A. Wood 7 Cloudflare 8 T. Reddy 9 McAfee 10 D. Migault 11 Ericsson 12 2 November 2020 14 Requirements for Adaptive DNS Discovery 15 draft-box-add-requirements-01 17 Abstract 19 Adaptive DNS Discovery is chartered to define mechanisms that allow 20 clients to discover and select encrypted DNS resolvers. This 21 document describes one common use case, that of discovering the 22 encrypted DNS resolver that corresponds to the Do53 resolver offered 23 by a network. It lists requirements that any proposed discovery 24 mechanisms should address. 26 Discussion Venues 28 This note is to be removed before publishing as an RFC. 30 Source for this draft and an issue tracker can be found at 31 https://github.com/ietf-wg-add/draft-add-requirements. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 6 May 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Requirements language . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Use case description . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Equivalence . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Local addressing . . . . . . . . . . . . . . . . . . . . 5 72 4. Network-identified encrypted resolvers . . . . . . . . . . . 5 73 5. Resolver-identified encrypted resolvers . . . . . . . . . . . 5 74 6. Privacy and security requirements . . . . . . . . . . . . . . 6 75 7. Statement of Requirements . . . . . . . . . . . . . . . . . . 7 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 10.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 Several protocols for protecting DNS traffic with encrypted 87 transports have been defined, such as DNS-over-TLS (DoT) [RFC7858] 88 and DNS-over-HTTPS (DoH) [RFC8484]. Encrypted DNS can provide many 89 security and privacy benefits for network clients. 91 While it is possible for clients to statically configure encrypted 92 DNS resolvers to use, dynamic discovery and provisioning of encrypted 93 resolvers can expand the usefulness and applicability of encrypted 94 DNS to many more use cases. 96 The Adaptive DNS Discovery (ADD) Working Group is chartered to define 97 mechanisms that allow clients to automatically discover and select 98 encrypted DNS resolvers in a wide variety of network environments. 99 This document currently focusses on one common use case, that of 100 discovering the encrypted DNS resolver that corresponds to the Do53 101 resolver offered by a network. Additional use cases can be added in 102 future versions. As well as describing the use case, it lists 103 requirements that any proposed discovery mechanisms should address. 104 They can do this either by providing a solution, or by explicitly 105 stating why it is not in scope. 107 1.1. Requirements language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 2. Terminology 117 This document makes use of the following terms. 119 Encrypted DNS: DNS-over-HTTPS [RFC8484], DNS-over-TLS [RFC7858], or 120 any other encrypted DNS technology that the IETF may publish, such as 121 DNS-over-QUIC [I-D.ietf-dprive-dnsoquic]. 123 Do53: Unencrypted DNS over UDP port 53, or TCP port 53 [RFC1035]. 125 Equivalent: See Section 3.1. 127 3. Use case description 129 It is often the case that a client possesses no specific 130 configuration for how to operate DNS, and at some point joins a 131 network that it has no previous knowledge about. In such a case the 132 usual existing behaviour is to dynamically discover the network's 133 recommended Do53 resolver and use it. This long-standing practice 134 works in nearly all networks, but presents a number of privacy and 135 security risks that were the motivation for the development of 136 encrypted DNS. 138 The network's recommended unencrypted resolver may have a number of 139 properties that differ from a generic resolver. It may be able to 140 answer names that are not known globally, it may exclude some names 141 (for positive or negative reasons), and it may provide address 142 answers that have improved proximity. In this use case it is assumed 143 that the user who chose to join this network would also like to make 144 use of these properties of the network's unencrypted resolver, at 145 least some of the time. However they would like to use an encrypted 146 DNS protocol rather than Do53. 148 Using an encrypted and authenticated resolver that is equivalent to 149 the one provisioned by the network can provide several benefits that 150 are not possible if only unencrypted DNS is used: 152 * Prevent other devices on the network from observing client DNS 153 messages 155 * Authenticate that the DNS resolver is the correct one 157 * Verify that answers come from the selected DNS resolver 159 To meet this case there should be a means by which the client can 160 learn how to contact an encrypted DNS resolver that provides 161 equivalent responses as the ones served by the network's recommended 162 unencrypted resolver. It is not a requirement that these two 163 resolvers are the same physical or logical machine. Often they will 164 be, but they could equally be separated, perhaps by hundreds of 165 miles. However it is deployed, the key is that they are equivalent. 167 3.1. Equivalence 169 Given two resolvers A and B, equivalence is the claim that A and B 170 can provide the same upper-layer DNS function to the client. This 171 does not include the DNS transport protocol (e.g. Do53 or DNS-over- 172 HTTPS) which can differ between equivalent resolvers. To provide 173 equivalence it is frequently likely to be the case that A and B are 174 operated by the same administrative domain, but this document does 175 not require that. 177 There are two possible ways to claim equivalence. 179 * The local network can claim that one or more encrypted DNS 180 resolvers (B, C, etc) are equivalent to the Do53 resolver (A) it 181 has offered. This is known as network-identified. 183 * During communication with the (often unencrypted) resolver (A), 184 this resolver can claim that one or more encrypted DNS resolvers 185 (B, C, etc) are equivalent. This is known as resolver-identified. 187 Network-identified is preferred since it comes from the same source 188 of information, and removes the need to talk to the Do53 resolver at 189 all. However it cannot be the sole mechanism, at least for several 190 years, since there is a large installed base of local network 191 equipment that is difficult to upgrade with new features. Hence the 192 second mechanism must support being able to announce an equivalent 193 resolver using only existing widely-deployed DNS features. 195 3.2. Local addressing 197 Many networks offer a Do53 resolver on an address that is not 198 globally meaningful, e.g. [RFC1918], link-local or unique local 199 addresses. To support the discovery of Encrypted DNS in these 200 environments, a means is needed for the discovery process to work 201 from a locally-addressed Do53 resolver to an Encrypted DNS resolver 202 that is accessible either at the same (local) address, or at a 203 different global address. Both options need to be supported. 205 4. Network-identified encrypted resolvers 207 DNS servers are often provisioned by a network as part of DHCP 208 options [RFC2132], IPv6 Router Advertisement (RA) options [RFC8106], 209 Point-to-Point Protocol (PPP) [RFC1877], or 3GPP Protocol 210 Configuration Options (TS24.008). Historically this is usually one 211 or more Do53 resolver IP addresses, to be used for traditional 212 unencrypted DNS. 214 A solution is required that enhances the set of information delivered 215 to include details of one or more equivalent encrypted DNS resolvers, 216 or states that there are none. 218 5. Resolver-identified encrypted resolvers 220 To support cases where the network is unable to identify an encrypted 221 resolver, it should be possible to learn the details of one or more 222 equivalent encrypted DNS resolvers by communicating with the network- 223 recommended unencrypted Do53 resolver. This should involve an 224 exchange that uses standard DNS messages that can be handled, or 225 forwarded, by existing deployed software. 227 It is frequently the case that Do53 resolvers announced by home 228 networks are difficult to upgrade to support encrypted operation. In 229 such cases it is possible that the only option for encrypted 230 operation is to refer to a separate globally-addressed encrypted DNS 231 resolver. 233 If the local resolver has been upgraded to support encrypted DNS, the 234 client may not initially be aware that its local resolver supports 235 it. Discovering this may require communication with the local 236 resolver, or an upstream resolver, over Do53. Clients that choose to 237 use this local encrypted DNS gain the benefits of encryption while 238 retaining the benefits of a local caching resolver with knowledge of 239 the local topology. 241 An additional benefit of using a local resolver occurs with IoT 242 devices. A common usage pattern for such devices is for it to "call 243 home" to a service that resides on the public Internet, where that 244 service is referenced through a domain name. As discussed in 245 Manufacturer Usage Description Specification [RFC8520], because these 246 devices tend to require access to very few sites, all other access 247 should be considered suspect. However, if the query is not 248 accessible for inspection, it becomes quite difficult for the 249 infrastructure to suspect anything. 251 6. Privacy and security requirements 253 Encrypted (and authenticated) DNS improves the privacy and security 254 of DNS queries and answers in the presence of malicious attackers. 255 Such attackers are assumed to interfere with or otherwise impede DNS 256 traffic and corresponding discovery mechanisms. They may be on-path 257 or off-path between the client and entities with which the client 258 communicates [RFC3552]. These attackers can inject, tamper, or 259 otherwise interfere with traffic as needed. Given these 260 capabilities, an attacker may have a variety of goals, including, 261 though not limited to: 263 * Monitor and profile clients by observing unencrypted DNS traffic 265 * Modify unencrypted DNS traffic to filter or augment the user 266 experience 268 * Block encrypted DNS 270 Given this type of attacker, resolver discovery mechanisms must be 271 designed carefully to not worsen a client's security or privacy 272 posture. In particular, attackers under consideration must not be 273 able to: 275 * Redirect secure DNS traffic to themselves when they would not 276 otherwise handle DNS traffic. 278 * Override or interfere with the resolver preferences of a user or 279 administrator. 281 * Cause clients to use a discovered resolver which has no 282 authenticated delegation from a client-known entity. 284 * Influence automatic discovery mechanisms such that a client uses 285 one or more resolvers that are not otherwise involved with 286 providing service to the client, such as: a network provider, a 287 VPN server, a content provider being accessed, or a server that 288 the client has manually configured. 290 When discovering DNS resolvers on a local network, clients have no 291 mechanism to distinguish between cases where an active attacker with 292 the above capabilities is interfering with discovery, and situations 293 wherein the network has no encrypted resolver. Absent such a 294 mechanism, an attacker can always succeed in these goals. Therefore, 295 in such circumstances, viable solutions for local DNS resolver 296 discovery should consider weaker attackers, such as those with only 297 passive eavesdropping capabilities. It is unknown whether such 298 relaxations represent a realistic attacker in practice. Thus, local 299 discovery solutions designed around this threat model may have 300 limited value. 302 7. Statement of Requirements 304 This section lists requirements that flow from the above sections. 306 +=============+=================================================+ 307 | Requirement | Description | 308 +=============+=================================================+ 309 | R1.1 | Discovery MUST provide a local network the | 310 | | ability to announce to clients a set of, or | 311 | | absence of, equivalent resolvers. | 312 +-------------+-------------------------------------------------+ 313 | R1.2 | Discovery MUST provide a resolver the ability | 314 | | to announce to clients a set of, or absence of, | 315 | | equivalent resolvers. | 316 +-------------+-------------------------------------------------+ 317 | R1.3 | Discovery MUST support at least one encrypted | 318 | | DNS protocol. | 319 +-------------+-------------------------------------------------+ 320 | R1.4 | Discovery SHOULD support all standardised | 321 | | encrypted DNS protocols. | 322 +-------------+-------------------------------------------------+ 323 | R2.1 | Networks MUST be able to announce one or more | 324 | | equivalent encrypted DNS resolvers using | 325 | | existing mechanisms such as DHCPv4, DHCPv6, | 326 | | IPv6 Router Advertisement, and the Point-to- | 327 | | Point Protocol. | 328 +-------------+-------------------------------------------------+ 329 | R2.2 | The format for resolver information MUST be | 330 | | specified such that provisioning mechanisms | 331 | | defined outside of the IETF can advertise | 332 | | encrypted DNS resolvers. | 333 +-------------+-------------------------------------------------+ 334 | R3.1 | When discovery is instantiated from a resolver | 335 | | (R1.2), that resolver MAY be encrypted or not. | 336 +-------------+-------------------------------------------------+ 337 | R3.2 | When discovery is instantiated from a resolver | 338 | | (R1.2), that resolver MAY be locally or | 339 | | globally reachable. Both options MUST be | 340 | | supported. | 341 +-------------+-------------------------------------------------+ 342 | R4.1 | In a home network use case, if the local | 343 | | network forwarder does not offer encrypted DNS | 344 | | service, the ISP's encrypted DNS server | 345 | | information MUST be retrievable via a query | 346 | | sent to a local network forwarder. | 347 +-------------+-------------------------------------------------+ 348 | R4.2 | Encrypted DNS server discovery MUST NOT require | 349 | | any changes to DNS forwarders hosted on non- | 350 | | upgradable legacy network devices. | 351 +-------------+-------------------------------------------------+ 352 | R5.1 | Discovery MUST NOT worsen a client's security | 353 | | or privacy posture. | 354 +-------------+-------------------------------------------------+ 355 | R5.2 | Threat modelling MUST assume that there is a | 356 | | passive eavesdropping attacker on the local | 357 | | network. | 358 +-------------+-------------------------------------------------+ 359 | R5.3 | Threat modelling MUST assume that an attacker | 360 | | can actively attack from outside the local | 361 | | network. | 362 +-------------+-------------------------------------------------+ 363 | R5.4 | Attackers MUST NOT be able to redirect | 364 | | encrypted DNS traffic to themselves when they | 365 | | would not otherwise handle DNS traffic. | 366 +-------------+-------------------------------------------------+ 367 | R5.5 | An attacker in the network MUST NOT be able to | 368 | | override or interfere with the resolver | 369 | | preferences of a user or administrator. | 370 +-------------+-------------------------------------------------+ 371 | R5.6 | Attackers MUST NOT be able to influence | 372 | | automatic discovery mechanisms such that a | 373 | | client uses one or more resolvers that are not | 374 | | otherwise involved with providing service to | 375 | | the client, including a network provider, a VPN | 376 | | server, a content provider being accessed, or a | 377 | | server that the client has manually configured. | 378 +-------------+-------------------------------------------------+ 380 Table 1 382 8. Security Considerations 384 See Section 6. 386 9. IANA Considerations 388 This document has no IANA actions. 390 10. References 392 10.1. Normative References 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 400 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 401 May 2017, . 403 10.2. Informative References 405 [I-D.ietf-dprive-dnsoquic] 406 Huitema, C., Mankin, A., and S. Dickinson, "Specification 407 of DNS over Dedicated QUIC Connections", Work in Progress, 408 Internet-Draft, draft-ietf-dprive-dnsoquic-01, 20 October 409 2020, . 412 [RFC1035] Mockapetris, P.V., "Domain names - implementation and 413 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 414 November 1987, . 416 [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol 417 Extensions for Name Server Addresses", RFC 1877, 418 DOI 10.17487/RFC1877, December 1995, 419 . 421 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 422 J., and E. Lear, "Address Allocation for Private 423 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 424 February 1996, . 426 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 427 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 428 . 430 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 431 Text on Security Considerations", BCP 72, RFC 3552, 432 DOI 10.17487/RFC3552, July 2003, 433 . 435 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 436 and P. Hoffman, "Specification for DNS over Transport 437 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 438 2016, . 440 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 441 "IPv6 Router Advertisement Options for DNS Configuration", 442 RFC 8106, DOI 10.17487/RFC8106, March 2017, 443 . 445 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 446 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 447 . 449 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 450 Description Specification", RFC 8520, 451 DOI 10.17487/RFC8520, March 2019, 452 . 454 Acknowledgments 456 This document was started based on discussion during the ADD meeting 457 of IETF108, the subsequent interims, on the list, and with text from 458 draft-pauly-add-requirements. In particular this document was 459 informed by contributions from Martin Thomson, Eric Rescorla, Tommy 460 Jensen, Ben Schwartz, Paul Hoffman, Ralf Weber, Michael Richardson, 461 Mohamed Boucadair, Sanjay Mishra, Jim Reid, Neil Cook, Nic Leymann 462 and Andrew Campling. 464 Authors' Addresses 466 Chris Box 467 BT 468 2000 Park Avenue 469 Bristol 470 United Kingdom 472 Email: chris.box@bt.com 473 Tommy Pauly 474 Apple 475 One Apple Park Way 476 Cupertino, California 95014, 477 United States of America 479 Email: tpauly@apple.com 481 Christopher A. Wood 482 Cloudflare 483 101 Townsend St 484 San Francisco, 485 United States of America 487 Email: caw@heapingbits.net 489 Tirumaleswar Reddy 490 McAfee 491 Embassy Golf Link Business Park 492 Bangalore 493 India 495 Email: TirumaleswarReddy_Konda@McAfee.com 497 Daniel Migault 498 Ericsson 499 8275 Trans Canada Route 500 Saint Laurent, QC 501 Canada 503 Email: daniel.migault@ericsson.com