idnits 2.17.1 draft-pauly-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (21 August 2020) is 1341 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-capport-architecture-09 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Pauly 3 Internet-Draft E. Kinnear 4 Intended status: Informational Apple Inc. 5 Expires: 22 February 2021 C.A. Wood 6 Cloudflare 7 P. McManus 8 Fastly 9 T. Jensen 10 Microsoft 11 21 August 2020 13 Adaptive DNS Discovery Requirements 14 draft-pauly-add-requirements-00 16 Abstract 18 This document describes several use cases for discovering DNS 19 resolvers that support encrypted transports, and discusses how 20 solutions for these use cases can be designed to use common 21 mechanisms. It also considers the requirements for privacy and 22 security when designing resolver discovery mechanisms. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 22 February 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 59 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Network-provisioned resolvers . . . . . . . . . . . . . . 3 61 2.2. Client-selected resolvers . . . . . . . . . . . . . . . . 3 62 2.3. VPN resolvers . . . . . . . . . . . . . . . . . . . . . . 4 63 2.4. Encrypted resolvers for private names . . . . . . . . . . 4 64 2.5. Encrypted resolvers for local or home content . . . . . . 5 65 2.6. Encrypted resolvers for content providers . . . . . . . . 5 66 3. Discovery mechanisms . . . . . . . . . . . . . . . . . . . . 6 67 4. Privacy and security requirements . . . . . . . . . . . . . . 6 68 4.1. On opportunistic encryption . . . . . . . . . . . . . . . 7 69 4.2. Handling exceptions and failures . . . . . . . . . . . . 8 70 5. Informative References . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Several protocols for protecting DNS traffic with encrypted 76 transports have been defined, such as DNS-over-TLS (DoT) [RFC7858] 77 and DNS-over-HTTPS (DoH) [RFC8484]. Encrypted DNS can provide many 78 security and privacy benefits for network clients. 80 While it is possible for clients to hard-code encrypted DNS resolvers 81 to use, dynamic discovery and provisioning of encrypted resolvers can 82 expand the usefulness and applicability of encrypted DNS to many more 83 use cases. 85 This document first describes several use cases for discovering DNS 86 resolvers that support encrypted transports (Section 2). 88 Next, it discusses how solutions for these use cases can be grouped 89 and categorized to point to the usefulness of common mechanisms 90 (Section 3). 92 Last, it considers the requirements for privacy and security when 93 designing resolver discovery mechanisms (Section 4). 95 This document is designed to aid in discussion of the Adaptive DNS 96 Discovery (ADD) working group as defines mechanism requirements. 98 1.1. Specification of Requirements 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 2. Use Cases 108 This section describes various use cases for which it is possible to 109 discover an encrypted resolver. For each use case, the privacy and 110 security benefits of adding encrypted resolution are briefly 111 described. 113 2.1. Network-provisioned resolvers 115 DNS servers are often provisioned by a network as part of DHCP 116 options [RFC2132] or IPv6 Router Advertisement (RA) options 117 [RFC8106]. These options describe one or more DNS resolver IP 118 addresses, to be used for traditional unencrypted DNS. 120 Using an encrypted resolver that is provisioned by the network can 121 provide several benefits that are not possible if only unencrypted 122 DNS is used: 124 * Prevent other devices on the network from observing client DNS 125 messages 127 * Verify that answers come from the selected DNS resolver 129 * Authenticate that the DNS resolver is the one provisioned by the 130 network 132 Often, network-provisioned resolvers are forwarders running on a 133 local router. The discovered encrypted resolvers in these cases may 134 either be local fowarders themselves, or an associated resolver that 135 is in the network (thus bypassing the router's DNS forwarder). 137 2.2. Client-selected resolvers 139 Client devices often allow a user or administrator to select a 140 specific DNS resolver to use on certain networks, or on all networks. 141 Historically, this selection was specified only with an IP address. 143 Discovering if the selected resolver supports encryption, along with 144 the configuration for the encrypted resolver, allows the client to 145 "upgrade" connections to use encrypted DNS. This can provide several 146 benefits: 148 * Prevent devices along the network path to the selected resolver 149 from observing client DNS messages 151 * Verify that answers come from the selected DNS resolver 153 * Authenticate that the DNS resolver is the one selected by the 154 client 156 2.3. VPN resolvers 158 Virtual Private Networks (VPNs) also can provision DNS resolvers. In 159 addition to being able to use DHCP or RAs, VPNs can provision DNS 160 information in an explicit configuration message. For example, IKEv2 161 can provision DNS servers using Configuration Attributes [RFC7296]. 163 VPNs can also configure Split DNS rules to limit the use of the 164 configured resolvers to specific domain names [RFC8598]. 166 Discovering an encrypted resolver that is provisioned by a VPN can 167 provide the same benefits as doing so for a local network, but 168 applied to the private network. When using Split DNS, it becomes 169 possible to use a one encrypted resolver for private domains, and 170 another for other domains. 172 2.4. Encrypted resolvers for private names 174 Similar to how VPN DNS configurations can use Split DNS for private 175 names, other network environments can support resolution of private 176 names. For example, an enterprise-managed Wi-Fi network might be 177 able to access both the Internet an a private intranet. In such a 178 scenario, the private domains managed by the enterprise might only be 179 resolvable using a specific DNS resolver. 181 Discovering an encrypted resolver for private domains allows a client 182 to perform Split DNS while maintaining the benefits of encrypted DNS. 183 For example, a client could use a client-selected encrypted resolver 184 for most domains, but use a different encrypted resolver for 185 enterprise-private domains. 187 This has the privacy benefit of only exposing DNS queries to the 188 enterprise that fall within a limited set of domains, if there is a 189 more preferred option for generic Internet traffic. 191 Using encrypted DNS for private names also opens up the possibility 192 of doing private name resolution outside of the content of a VPN or 193 managed network. If the DNS resolver authenticates clients, it can 194 offer its resolver for private names on a publicly accessible server, 195 while still limiting the visibility of the DNS traffic. 197 2.5. Encrypted resolvers for local or home content 199 Accessing locally-hosted content can require the use of a specific 200 resolver. For example, captive networks or networks with walled- 201 garden content like media on airplane Wi-Fi networks can rely on 202 using a resolver hosted on the local network. 204 In cases where a client is using an encrypted resolver provisioned by 205 a network, and that encrypted resolver is able to resolve names local 206 content, this can fall into the use case described in Section 2.1. 207 However, it might be necessary to discover a local encrypted resolver 208 along with specific domains if: 210 * the network-provisioned encrypted resolver is not able to resolve 211 local-only names, or 213 * the client has a more-preferred encrypted resolver for generic 214 traffic, and would otherwise not be able to access local content 216 This case also include accessing content specific to a home network. 218 2.6. Encrypted resolvers for content providers 220 Content Delivery Networks (CDNs), and content-providers more broadly, 221 can also provide encrypted DNS resolvers that can be used by clients 222 over the public Internet. These resolvers can either allow 223 resolution of all public names (like normal recursive resolvers), or 224 be designed to serve a subset of names managed by the content 225 provider (like an authoritative resolver). Using these resolvers can 226 allow the content provider to directly control how DNS answers are 227 used for load balancing and address selection, which could improve 228 performance of connections to the content provider. 230 Using a content-provider's encrypted resolver can also provide 231 several privacy and security benefits: 233 * Prevent devices along the network path to the content-provider's 234 resolver from observing client DNS messages 236 * Verify that answers come from the entity that manages the domains 237 being resolved 239 * Reduce the number of entities able to monitor the specific names 240 accessed by a client to only the client and the content provider, 241 assuming that the content provider would already see the names 242 upon a secure connection later being made based on the DNS answers 243 (e.g., in the TLS SNI extension) 245 3. Discovery mechanisms 247 The use cases described in Section 2 do not all necessarily require 248 separate mechanisms. 250 Generally, the use cases can be summarized in two categories: 252 1. Resolver upgrade: Discover encrypted resolvers equivalent to (or 253 associated with) unencrypted resolvers. Examples include 254 network-provisioned, client-selected, and VPN-configured 255 resolvers. 257 2. Domain-specific resolvers: Discover encrypted resolvers 258 applicable to a limited set of domains. Examples include 259 resolvers for enterprise or private names, local content, and CDN 260 content. 262 Resolver upgrade mechanisms can either add new parameters to existing 263 provisioning mechanisms (adding necessary information to use DoT or 264 DoH to options in DHCP, RAs, or IKEv2) or else provide a way to 265 communicate with a provisioned unencrypted DNS resolver and discover 266 the equivalent or associated encrypted DNS resolver. 268 Domain-specific resolver discovery mechanisms additionally need to 269 provide some information about the applicability and capabilities of 270 encrypted resolvers. This information can either be provisioned or 271 can be discovered based on clients actively trying to access content. 273 4. Privacy and security requirements 275 Encrypted DNS improves the privacy and security of DNS queries and 276 answers in the presence of malicious attackers. Such attackers are 277 assumed to interfere with or otherwise impede DNS traffic and 278 corresponding discovery mechanisms. They may be on-path or off-path 279 between the client and entities with which the client communicates 280 [RFC3552]. These attackers can inject, tamper, or otherwise 281 interfere with traffic as needed. Given these capabilities, an 282 attacker may have a variety of goals, including, though not limited 283 to: 285 * Monitor and profile clients by observing unencrypted DNS traffic 286 * Modify unencrypted DNS traffic to filter or augment the user 287 experience 289 * Block encrypted DNS 291 Clients cannot assume that their network does not have such an 292 attacker unless given some means of authenticating or otherwise 293 trusting the communication with their DNS resolver. 295 Given this type of attacker, resolver discovery mechanisms must be 296 designed carefully to not worsen a client's security or privacy 297 posture. In particular, attackers must not be able to: 299 * Redirect DNS traffic to themselves. 301 * Override or interfere with the resolver preferences of a user or 302 administrator. 304 * Cause clients to use a discovered resolver which has no 305 authenticated delegation from a client-known entity. 307 * Influence automatic discovery mechanisms such that a client uses 308 one or more resolvers that are not otherwise involved with 309 providing service to the client, such as: a network provider, a 310 VPN server, a content provider being accessed, or a server that 311 the client has manually configured. 313 Beyond these requirements, standards describing resolver discovery 314 mechanisms must not place any requirements on clients to select 315 particular resolvers over others. 317 4.1. On opportunistic encryption 319 Opportunistic encrypted DNS, when the client cannot authenticate the 320 entity that provides encrypted DNS, does not meet the requirements 321 laid out here for resolver discovery. While opportunistic encryption 322 can provide some benefits, specifically in reducing the ability for 323 other entities to observe traffic, it is not a viable solution 324 against an on-path attacker. 326 Performing opportunistic encrypted DNS does not require specific 327 discovery mechanisms. Section 4.1 of [RFC7858] already describes how 328 to use DNS-over-TLS opportunistically. 330 4.2. Handling exceptions and failures 332 Even with encrypted DNS resolver discovery in place, clients must be 333 prepared to handle certain scenarios where encrypted DNS cannot be 334 used. In these scenarios, clients must consider if it is appropriate 335 to fail open by sending the DNS queries without encryption, fail 336 closed by not doing so, or presenting a choice to a user or 337 administrator. The exact behavior is a local client policy decision. 339 Some networks that use Captive Portals will not allow any Internet 340 connectivity until a client has interacted with the portal 341 [I-D.ietf-capport-architecture]. If these networks do not use 342 encrypted DNS for their own resolution, a client will need to perform 343 unencrypted DNS queries in order to get out of captivity. Many 344 operating systems have specific client code responsible for detecting 345 and interacting with Captive Portals; these system components may be 346 good candidates for failing open, since they do not generally 347 represent user traffic. 349 Other networks may not allow any use of encrypted DNS, or any use of 350 encrypted DNS to resolvers other than a network-provisioned resolver. 351 Clients should not silently fail open in these cases, but if these 352 networks are trusted by or administered by the user, the user may 353 want to specifically follow the network's DNS policy instead of what 354 the client would do on an unknown or untrusted network. 356 5. Informative References 358 [I-D.ietf-capport-architecture] 359 Larose, K., Dolson, D., and H. Liu, "Captive Portal 360 Architecture", Work in Progress, Internet-Draft, draft- 361 ietf-capport-architecture-09, 8 August 2020, 362 . 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, 367 DOI 10.17487/RFC2119, March 1997, 368 . 370 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 371 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 372 . 374 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 375 Text on Security Considerations", BCP 72, RFC 3552, 376 DOI 10.17487/RFC3552, July 2003, 377 . 379 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 380 Kivinen, "Internet Key Exchange Protocol Version 2 381 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 382 2014, . 384 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 385 and P. Hoffman, "Specification for DNS over Transport 386 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 387 2016, . 389 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 390 "IPv6 Router Advertisement Options for DNS Configuration", 391 RFC 8106, DOI 10.17487/RFC8106, March 2017, 392 . 394 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 395 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 396 May 2017, . 398 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 399 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 400 . 402 [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the 403 Internet Key Exchange Protocol Version 2 (IKEv2)", 404 RFC 8598, DOI 10.17487/RFC8598, May 2019, 405 . 407 Authors' Addresses 409 Tommy Pauly 410 Apple Inc. 411 One Apple Park Way 412 Cupertino, California 95014, 413 United States of America 415 Email: tpauly@apple.com 417 Eric Kinnear 418 Apple Inc. 419 One Apple Park Way 420 Cupertino, California 95014, 421 United States of America 423 Email: ekinnear@apple.com 424 Christopher A. Wood 425 Cloudflare 426 101 Townsend St 427 San Francisco, 428 United States of America 430 Email: caw@heapingbits.net 432 Patrick McManus 433 Fastly 435 Email: mcmanus@ducksong.com 437 Tommy Jensen 438 Microsoft 440 Email: tojens@microsoft.com