idnits 2.17.1 draft-ietf-add-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 -- The document date (7 March 2021) is 1147 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-02 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: 8 September 2021 Apple 6 C.A. Wood 7 Cloudflare 8 T. Reddy 9 McAfee 10 D. Migault 11 Ericsson 12 7 March 2021 14 Requirements for Discovering Designated Resolvers 15 draft-ietf-add-requirements-00 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, namely that of clients that 22 connect to a network but where they cannot securely authenticate the 23 identity of that network. In such cases the client would like to 24 learn which encrypted DNS resolvers are designated by that network or 25 by the Do53 resolver offered by that network. It lists requirements 26 that any proposed discovery mechanisms should seek to address. 28 Discussion Venues 30 Source for this draft can be found at https://github.com/ietf-wg-add/ 31 draft-ietf-add-requirements/. 33 Discussion of this document and associated solutions takes place in 34 the ADD Working Group mailing list (add@ietf.org), which is archived 35 at https://mailarchive.ietf.org/arch/browse/add/. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 8 September 2021. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Requirements language . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Use case description . . . . . . . . . . . . . . . . . . . . 4 74 3.1. Designation . . . . . . . . . . . . . . . . . . . . . . . 4 75 3.2. Local addressing . . . . . . . . . . . . . . . . . . . . 5 76 3.3. Use of designation information . . . . . . . . . . . . . 5 77 3.4. Network-identified designated resolvers . . . . . . . . . 6 78 3.5. Resolver-identified designated resolvers . . . . . . . . 6 79 3.5.1. Local to local . . . . . . . . . . . . . . . . . . . 6 80 3.5.2. Local to upstream . . . . . . . . . . . . . . . . . . 7 81 3.5.3. Public to public . . . . . . . . . . . . . . . . . . 7 82 3.6. Identification over an encrypted channel . . . . . . . . 8 83 4. Privacy and security requirements . . . . . . . . . . . . . . 8 84 5. Statement of Requirements . . . . . . . . . . . . . . . . . . 9 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 89 8.2. Informative References . . . . . . . . . . . . . . . . . 11 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 93 1. Introduction 95 Several protocols for protecting DNS traffic with encrypted 96 transports have been defined, such as DNS-over-TLS (DoT) [RFC7858] 97 and DNS-over-HTTPS (DoH) [RFC8484]. Encrypted DNS can provide many 98 security and privacy benefits for network clients. 100 While it is possible for clients to statically configure encrypted 101 DNS resolvers to use, dynamic discovery and provisioning of encrypted 102 resolvers can expand the usefulness and applicability of encrypted 103 DNS to many more use cases. 105 The Adaptive DNS Discovery (ADD) Working Group is chartered to define 106 mechanisms that allow clients to automatically discover and select 107 encrypted DNS resolvers in a wide variety of network environments. 108 This document describes one common use case, namely that of clients 109 that connect to a network but where they cannot securely authenticate 110 that network. Whether the network required credentials before the 111 client was permitted to join is irrelevant; the client still cannot 112 be sure that it has connected to the network it was expecting. 114 In such cases the client would like to learn which encrypted DNS 115 resolvers are designated by that network, or by the Do53 resolver 116 offered by that network. It lists requirements that any proposed 117 discovery mechanisms should seek to address. They can do this either 118 by providing a solution, or by explicitly stating why it is not in 119 scope. 121 1.1. Requirements language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 2. Terminology 131 This document makes use of the following terms. 133 Encrypted DNS: DNS-over-HTTPS [RFC8484], DNS-over-TLS [RFC7858], or 134 any other encrypted DNS technology that the IETF may publish, such as 135 DNS-over-QUIC [I-D.ietf-dprive-dnsoquic]. 137 Do53: Unencrypted DNS over UDP port 53, or TCP port 53 [RFC1035]. 139 Designated: See Section 3.1. 141 Designator: The network or resolver that issued the designation. 143 3. Use case description 145 It is often the case that a client possesses no specific 146 configuration for how to operate DNS, and at some point joins a 147 network that it cannot authenticate. It may have no prior knowledge 148 of the network, or it may have connected previously to a network that 149 looked the same. In either case the usual behaviour, because of lack 150 of specific configuration, is to dynamically discover the network's 151 designated Do53 resolver and use it. This long-standing practice 152 works in nearly all networks, but presents a number of privacy and 153 security risks that were the motivation for the development of 154 encrypted DNS. 156 The network's designated Do53 resolver may have a number of 157 properties that differ from a generic resolver. It may be able to 158 answer names that are not known globally, it may exclude some names 159 (for positive or negative reasons), and it may provide address 160 answers that have improved proximity. In this use case it is assumed 161 that the user who chose to join this network would also like to make 162 use of these properties of the network's unencrypted resolver, at 163 least some of the time. However they would like to use an encrypted 164 DNS protocol rather than Do53. 166 Using an encrypted and authenticated resolver can provide several 167 benefits that are not possible if only unencrypted DNS is used: 169 * Prevent other devices on the network from observing client DNS 170 messages 172 * Authenticate that the DNS resolver is the correct one 174 * Verify that answers come from the selected DNS resolver 176 To meet this case there should be a means by which the client can 177 learn how to contact a set of encrypted DNS resolvers that are 178 designated by the network it has joined. 180 3.1. Designation 182 Designation is the process by which a local network or a resolver can 183 point clients towards a particular set of resolvers. This is not a 184 new concept, as networks have been able to dynamically designate Do53 185 resolvers for decades (see Section 3.4). However here we extend the 186 concept in two ways: 188 * To allow resolvers to designate other resolvers 189 * The inclusion of support for encrypted DNS 191 The designated set could be empty, or it could list the contact 192 details (such as DoH URI Template) of DNS resolvers that it 193 recommends. It is not required that there be any relationship 194 between the resolvers in the set, simply that all of them are options 195 that the designator asserts are safe and appropriate for the client 196 to use without user intervention. 198 There are two possible sources of designation. 200 * The local network can designate one or more encrypted DNS 201 resolvers (B, C, etc) in addition to any Do53 resolver (A) it may 202 offer. This is known as network-identified. 204 * During communication with the (often unencrypted) resolver (A), 205 this resolver can designate one or more encrypted DNS resolvers 206 (B, C, etc). This is known as resolver-identified. 208 Network-identified has the advantages that it derives from the same 209 source of information as the network's Do53 announcement, and removes 210 the need to talk to the Do53 resolver at all. However it cannot be 211 the sole mechanism, at least for several years, since there is a 212 large installed base of local network equipment that is difficult to 213 upgrade with new features. Hence the second mechanism should support 214 being able to designate resolvers using only existing widely-deployed 215 DNS features. 217 3.2. Local addressing 219 Many networks offer a Do53 resolver on an address that is not 220 globally meaningful, e.g. [RFC1918], link-local or unique local 221 addresses. To support the discovery of encrypted DNS in these 222 environments, a means is needed for the discovery process to work 223 from a locally-addressed Do53 resolver to an encrypted DNS resolver 224 that is accessible either at the same (local) address, or at a 225 different global address. Both options need to be supported. 227 3.3. Use of designation information 229 After the client receives designation information, it must come to a 230 decision on whether and when to use any of the designated resolvers. 232 In the case of resolver-identified designation, it would be 233 advantageous for a solution to enable the client to validate the 234 source of the assertion in some way. For example it may be possible 235 to verify that the designation comes from an entity who already has 236 full control of the client's Do53 queries. Network-identified 237 designation should not require this, unless the network-identified 238 resolver in turn initiated a new resolver-identified designation. It 239 would be beneficial to extend such a verification process to defend 240 against attackers that have only transient control of such queries. 242 Clients may also seek to validate the identity of the designated 243 resolver, beyond what is required by the relevant protocol. Authors 244 of solution specifications should be aware that clients may impose 245 arbitrary additional requirements and heuristics as they see fit. 247 3.4. Network-identified designated resolvers 249 DNS servers are often provisioned by a network as part of DHCP 250 options [RFC2132], IPv6 Router Advertisement (RA) options [RFC8106], 251 Point-to-Point Protocol (PPP) [RFC1877], or 3GPP Protocol 252 Configuration Options (TS24.008). Historically this is usually one 253 or more Do53 resolver IP addresses, to be used for traditional 254 unencrypted DNS. 256 A solution is required that enhances the set of information delivered 257 to include details of one or more designated encrypted DNS resolvers, 258 or states that there are none. Such resolvers could be on the local 259 network, somewhere upstream, or on the public Internet. 261 3.5. Resolver-identified designated resolvers 263 To support cases where the network is unable to identify an encrypted 264 resolver, it should be possible to learn the details of one or more 265 designated encrypted DNS resolvers by communicating with the 266 network's designated Do53 resolver. This should involve an exchange 267 that uses standard DNS messages that can be handled, or forwarded, by 268 existing deployed software. 270 Each resolver in the set may be at a different network location, 271 which leads to several subcases for the mapping from Do53 to a 272 particular designated resolver. 274 3.5.1. Local to local 276 If the local resolver has been upgraded to support encrypted DNS, the 277 client may not initially be aware that its local resolver supports 278 it. Discovering this may require communication with the local 279 resolver, or an upstream resolver, over Do53. Clients that choose to 280 use this local encrypted DNS gain the benefits of encryption while 281 retaining the benefits of a local caching resolver with knowledge of 282 the local topology. 284 Clients will be aware when the designated resolver has the same IP 285 address as the Do53 (after looking up its name if required). They 286 can use this information in their decision-making as to the level of 287 trust to place in the designated resolver. In some networks it will 288 not be possible to deploy encrypted DNS on the same IP address, e.g. 289 because of the increased resource requirements of encrypted DNS. 290 Discovery solutions should work in the presence of a change to a 291 different local IP address. 293 An additional benefit of using a local resolver occurs with IoT 294 devices. A common usage pattern for such devices is for it to "call 295 home" to a service that resides on the public Internet, where that 296 service is referenced through a domain name. As discussed in 297 Manufacturer Usage Description Specification [RFC8520], because these 298 devices tend to require access to very few sites, all other access 299 should be considered suspect. However, if the query is not 300 accessible for inspection, it becomes quite difficult for the 301 infrastructure to suspect anything. 303 3.5.2. Local to upstream 305 It is frequently the case that Do53 resolvers announced by home 306 networks are difficult to upgrade to support encrypted operation. In 307 such cases it is possible that the only option for encrypted 308 operation is to refer to a separate globally-addressed encrypted DNS 309 resolver, somewhere upstream. Other networks may choose deploy their 310 encrypted DNS resolver away from the local network, for other 311 reasons. 313 The use of an upstream resolver can mean the loss of local knowledge, 314 such as the ability to respond to queries for locally-relevant names. 315 Solutions should consider how to guide clients when to direct their 316 queries to the local Do53. For example this could be through pre- 317 emptive communication ("if you ever need to query *.example.com, use 318 your local Do53"), or reactively ("I don't know the answer to that, 319 but your local Do53 should know"). 321 3.5.3. Public to public 323 In cases where the local network has designated a Do53 resolver on 324 the public Internet, this resolver may designate its own or another 325 public encrypted DNS service. Since public IP addresses may appear 326 in TLS certificates, solutions may use this as one way to validate 327 that the designated encrypted resolver is legitimately associated 328 with the original Do53. 330 3.6. Identification over an encrypted channel 332 In cases where the designation is delivered over an authenticated and 333 encrypted channel, such as when one encrypted DNS resolver designates 334 another, one form of attack is removed. Specifically, clients may be 335 more confident that the received designation was actually sent by the 336 designator. Clients may take this into account when deciding whether 337 to follow the designation. 339 4. Privacy and security requirements 341 Encrypted (and authenticated) DNS improves the privacy and security 342 of DNS queries and answers in the presence of malicious attackers. 343 Such attackers are assumed to interfere with or otherwise impede DNS 344 traffic and corresponding discovery mechanisms. They may be on-path 345 or off-path between the client and entities with which the client 346 communicates [RFC3552]. These attackers can inject, tamper, or 347 otherwise interfere with traffic as needed. Given these 348 capabilities, an attacker may have a variety of goals, including, 349 though not limited to: 351 * Monitor and profile clients by observing unencrypted DNS traffic 353 * Modify unencrypted DNS traffic to filter or augment the user 354 experience 356 * Block encrypted DNS 358 Given this type of attacker, resolver discovery mechanisms must be 359 designed carefully to not worsen a client's security or privacy 360 posture. In particular, attackers under consideration must not be 361 able to: 363 * Redirect secure DNS traffic to themselves when they would not 364 otherwise handle DNS traffic. 366 * Override or interfere with the resolver preferences of a user or 367 administrator. 369 * Cause clients to use a discovered resolver which has no 370 designation from a client-known entity. 372 When discovering DNS resolvers on a local network, clients have no 373 mechanism to distinguish between cases where an active attacker with 374 the above capabilities is interfering with discovery, and situations 375 wherein the network has no encrypted resolver. Absent such a 376 mechanism, an attacker can always succeed in these goals. Therefore, 377 in such circumstances, viable solutions for local DNS resolver 378 discovery should consider weaker attackers, such as those with only 379 passive eavesdropping capabilities. It is unknown whether such 380 relaxations represent a realistic attacker in practice. Thus, local 381 discovery solutions designed around this threat model may have 382 limited value. 384 5. Statement of Requirements 386 This section lists requirements that flow from the above sections. 388 +=============+===================================================+ 389 | Requirement | Description | 390 +=============+===================================================+ 391 | R1.1 | Discovery SHOULD provide a local network the | 392 | | ability to announce to clients a set of, or | 393 | | absence of, designated resolvers. | 394 +-------------+---------------------------------------------------+ 395 | R1.2 | Discovery SHOULD provide a resolver the ability | 396 | | to announce to clients a set of, or absence of, | 397 | | designated resolvers. | 398 +-------------+---------------------------------------------------+ 399 | R1.3 | Discovery SHOULD support all encrypted DNS | 400 | | protocols standardised by the IETF. | 401 +-------------+---------------------------------------------------+ 402 | R2.1 | Networks SHOULD be able to announce one or more | 403 | | designated encrypted DNS resolvers using existing | 404 | | mechanisms such as DHCPv4, DHCPv6, IPv6 Router | 405 | | Advertisement, and the Point-to-Point Protocol. | 406 +-------------+---------------------------------------------------+ 407 | R2.2 | The format for resolver designation SHOULD be | 408 | | specified such that provisioning mechanisms | 409 | | defined outside of the IETF can advertise | 410 | | encrypted DNS resolvers. | 411 +-------------+---------------------------------------------------+ 412 | R2.3 | This format SHOULD convey, at minimum, the | 413 | | information the client needs to make contact with | 414 | | each designated resolver. | 415 +-------------+---------------------------------------------------+ 416 | R2.4 | This format MAY convey additional resolver | 417 | | information. | 418 +-------------+---------------------------------------------------+ 419 | R3.1 | In resolver-identified designation (R1.2), the | 420 | | communication with the designator MAY be | 421 | | encrypted or not, depending on the capability of | 422 | | the resolver. | 423 +-------------+---------------------------------------------------+ 424 | R3.2 | In resolver-identified designation (R1.2), that | 425 | | resolver MAY be locally or globally reachable. | 426 | | Both options SHOULD be supported. | 427 +-------------+---------------------------------------------------+ 428 | R4.1 | If the local network resolver is a forwarder that | 429 | | does not offer encrypted DNS service, an upstream | 430 | | encrypted resolver SHOULD be retrievable via | 431 | | queries sent to that forwarder. | 432 +-------------+---------------------------------------------------+ 433 | R4.2 | Achieving requirement 4.1 SHOULD NOT require any | 434 | | changes to DNS forwarders hosted on non- | 435 | | upgradable legacy network devices. | 436 +-------------+---------------------------------------------------+ 437 | R5.1 | Discovery MUST NOT worsen a client's security or | 438 | | privacy posture. | 439 +-------------+---------------------------------------------------+ 440 | R5.2 | Threat modelling MUST assume that there is a | 441 | | passive eavesdropping attacker on the local | 442 | | network. | 443 +-------------+---------------------------------------------------+ 444 | R5.3 | Threat modelling MUST assume that an attacker can | 445 | | actively attack from outside the local network. | 446 +-------------+---------------------------------------------------+ 447 | R5.4 | Attackers MUST NOT be able to redirect encrypted | 448 | | DNS traffic to themselves when they would not | 449 | | otherwise handle DNS traffic. | 450 +-------------+---------------------------------------------------+ 452 Table 1 454 6. Security Considerations 456 See Section 4. 458 7. IANA Considerations 460 This document has no IANA actions. 462 8. References 464 8.1. Normative References 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, 468 DOI 10.17487/RFC2119, March 1997, 469 . 471 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 472 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 473 May 2017, . 475 8.2. Informative References 477 [I-D.ietf-dprive-dnsoquic] 478 Huitema, C., Mankin, A., and S. Dickinson, "Specification 479 of DNS over Dedicated QUIC Connections", Work in Progress, 480 Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February 481 2021, . 484 [RFC1035] Mockapetris, P., "Domain names - implementation and 485 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 486 November 1987, . 488 [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol 489 Extensions for Name Server Addresses", RFC 1877, 490 DOI 10.17487/RFC1877, December 1995, 491 . 493 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 494 J., and E. Lear, "Address Allocation for Private 495 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 496 February 1996, . 498 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 499 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 500 . 502 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 503 Text on Security Considerations", BCP 72, RFC 3552, 504 DOI 10.17487/RFC3552, July 2003, 505 . 507 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 508 and P. Hoffman, "Specification for DNS over Transport 509 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 510 2016, . 512 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 513 "IPv6 Router Advertisement Options for DNS Configuration", 514 RFC 8106, DOI 10.17487/RFC8106, March 2017, 515 . 517 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 518 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 519 . 521 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 522 Description Specification", RFC 8520, 523 DOI 10.17487/RFC8520, March 2019, 524 . 526 Acknowledgments 528 This document was started based on discussion during the ADD meeting 529 of IETF108, subsequent meetings, on the list, and with text from 530 draft-pauly-add-requirements. In particular this document was 531 informed by contributions from Martin Thomson, Eric Rescorla, Tommy 532 Jensen, Ben Schwartz, Paul Hoffman, Ralf Weber, Michael Richardson, 533 Mohamed Boucadair, Sanjay Mishra, Jim Reid, Neil Cook, Nic Leymann, 534 Andrew Campling, Eric Orth, Ted Hardie, Paul Vixie, Vittorio Bertola, 535 and Vinny Parla. 537 Authors' Addresses 539 Chris Box 540 BT 541 2000 Park Avenue 542 Bristol 543 United Kingdom 545 Email: chris.box@bt.com 547 Tommy Pauly 548 Apple 549 One Apple Park Way 550 Cupertino, California 95014, 551 United States of America 553 Email: tpauly@apple.com 555 Christopher A. Wood 556 Cloudflare 557 101 Townsend St 558 San Francisco, 559 United States of America 561 Email: caw@heapingbits.net 563 Tirumaleswar Reddy 564 McAfee 565 Embassy Golf Link Business Park 566 Bangalore 567 India 569 Email: TirumaleswarReddy_Konda@McAfee.com 571 Daniel Migault 572 Ericsson 573 8275 Trans Canada Route 574 Saint Laurent, QC 575 Canada 577 Email: daniel.migault@ericsson.com