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