idnits 2.17.00 (12 Aug 2021) /tmp/idnits39884/draft-schwartz-add-ddr-forwarders-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 : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 121: '...esolver, clients MUST validate that th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 October 2021) is 204 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-add-ddr-03 == Outdated reference: A later version (-07) exists of draft-ietf-add-dnr-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive B. Schwartz 3 Internet-Draft Google LLC 4 Intended status: Informational C. Box 5 Expires: 25 April 2022 BT 6 22 October 2021 8 Discovery of Designated Resolvers in the Presence of Legacy Forwarders 9 draft-schwartz-add-ddr-forwarders-01 11 Abstract 13 This draft describes how the Discovery of Designated Resolvers (DDR) 14 standard interacts with legacy DNS forwarders, including potential 15 incompatibilities and relevant mitigations. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Discussion of this document takes place on the mailing list 22 (add@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/browse/add/. 25 Source for this draft and an issue tracker can be found at 26 https://github.com/bemasc/ddr-forwarders. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 25 April 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Relaxed Validation client policy . . . . . . . . . . . . . . 4 66 4. Naturally compatible behaviors . . . . . . . . . . . . . . . 4 67 4.1. Compatible behaviors in the local network . . . . . . . . 4 68 4.1.1. Malware and threat domain filtering . . . . . . . . . 4 69 4.1.2. Service category restrictions . . . . . . . . . . . . 4 70 4.1.3. Time of use restrictions . . . . . . . . . . . . . . 5 71 4.2. Upstream resolver services . . . . . . . . . . . . . . . 5 72 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 74 6.1. Transient attackers . . . . . . . . . . . . . . . . . . . 6 75 6.1.1. Solution: DNR . . . . . . . . . . . . . . . . . . . . 6 76 6.1.2. Mitigation: Frequent refresh . . . . . . . . . . . . 6 77 6.1.3. Mitigation: Resolver reputation . . . . . . . . . . . 6 78 6.2. Forensic logging . . . . . . . . . . . . . . . . . . . . 6 79 6.2.1. Network-layer logging . . . . . . . . . . . . . . . . 6 80 6.2.2. DNS-layer logging . . . . . . . . . . . . . . . . . . 7 81 7. Compatibility Considerations . . . . . . . . . . . . . . . . 7 82 7.1. Split-horizon namespaces . . . . . . . . . . . . . . . . 7 83 7.1.1. Mitigation: NXDOMAIN Fallback . . . . . . . . . . . . 7 84 7.2. Interposable domains . . . . . . . . . . . . . . . . . . 8 85 7.2.1. Mitigation: Exemption list . . . . . . . . . . . . . 8 86 7.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 7.3.1. Mitigation: Stub caches . . . . . . . . . . . . . . . 8 88 7.4. General mitigation: User controls . . . . . . . . . . . . 9 89 8. Informative References . . . . . . . . . . . . . . . . . . . 9 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 93 1. Conventions and Definitions 95 Private IP Address - Any IP address reserved for loopback [RFC1122], 96 link-local [RFC3927], private [RFC1918], local [RFC4193], or Carrier- 97 Grade NAT [RFC6598] use. 99 Legacy DNS Forwarder - An apparent DNS resolver, known to the client 100 only by a private IP address, that forwards the client's queries to 101 an upstream resolver, and has not been updated with any knowledge of 102 DDR. 104 Cross-Forwarder Upgrade - Establishment of a direct, encrypted 105 connection between the client and the upstream resolver. 107 2. Introduction 109 2.1. Background 111 The Discovery of Designated Resolvers specification [DDR] describes a 112 mechanism for clients to learn about the encrypted protocols 113 supported by a DNS server. It also describes a conservative client 114 validation policy that has strong security properties and is unlikely 115 to create compatibility problems. 117 On the topic of client validation of encrypted DNS transports, the 118 DDR specification says: 120 If the IP address of a Designated Resolver differs from that of an 121 Unencrypted Resolver, clients MUST validate that the IP address of 122 the Unencrypted Resolver is covered by the SubjectAlternativeName 123 of the Encrypted Resolver's TLS certificate 125 As TLS certificates cannot cover private IP addresses, this prevents 126 clients that are behind a legacy DNS forwarder from connecting 127 directly to the upstream resolver ("cross-forwarder upgrade"). 129 Recent estimates suggest that a large fraction, perhaps a majority, 130 of residential internet users in the United States and Europe rely on 131 local DNS forwarders that are not compatible with DDR. 133 2.2. Scope 135 This informational document describes the interaction between DDR and 136 legacy DNS forwarders. It discusses possible client policies, 137 problems that might arise, and relevant mitigations. 139 DNS forwarders and resolvers that are implemented with awareness of 140 DDR are out of scope, as they are not affected by this discussion 141 (although see Security Considerations, Section 6). 143 IPv6-only networks whose default DNS server has a Global Unicast 144 Address are out of scope, even if this server is actually a simple 145 forwarder. If the DNS server does not use a private IP address, it 146 is not a "legacy DNS forwarder" under this draft's definition. 148 3. Relaxed Validation client policy 150 We define a "relaxed validation" client policy as a client behavior 151 that removes the certificate validation requirement when the 152 Unencrypted Resolver is identified by a private IP address, 153 regardless of the Designated Resolver's IP address. Instead, under 154 this condition, the client connects using the Opportunistic Privacy 155 Profile of encrypted DNS ([RFC7858], Section 4.1). 157 The Opportunistic Privacy Profile is a broad category, including 158 clients that "might or might not validate" the TLS certificate chain 159 even though there is no authentication identity for the server. This 160 kind of validation can be valuable when combined with a reputation 161 system or a user approval step (see Section 6.1.3 and Section 7.4). 163 This client policy is otherwise identical to the one described in 164 Section 4 of [DDR]. 166 4. Naturally compatible behaviors 168 The following system behaviors are naturally compatible with relaxed 169 validation. 171 4.1. Compatible behaviors in the local network 173 4.1.1. Malware and threat domain filtering 175 Certain DNS forwarders block access to domains associated with 176 malware and other threats. Such threats rely on frequently changing 177 domains, so these forwarders necessarily maintain an actively curated 178 list of domains to block. To ensure that this service is not lost 179 due to a cross-forwarder upgrade, the maintainers can simply add 180 "resolver.arpa" to the list. 182 This pattern has been deployed by Mozilla, with the domain "use- 183 application-dns.net" [MOZILLA-CANARY]. 185 4.1.2. Service category restrictions 187 Certain DNS forwarders may block access to domains based on the 188 category of service provided by those domains, e.g. domains hosting 189 services that are not appropriate for a work or school environment. 190 As in the previous section, this requires an actively curated list of 191 domains, because the set of domains that offer a given type of 192 service is constantly changing. An actively managed blocking list 193 can easily be revised to include "resolver.arpa". 195 4.1.3. Time of use restrictions 197 Certain networks may impose restrictions on the time or duration of 198 use by certain users. This behavior is necessarily implemented below 199 the DNS layer, because DNS-based blocking would be ineffective due to 200 stub resolver caching, so it is not affected by changes in the DNS 201 resolver. 203 4.2. Upstream resolver services 205 The forwarder's upstream resolver might provide additional services, 206 such as filtering. These services are generally independent of 207 cross-forwarder upgrade, and hence naturally compatible. 209 In special cases where the upstream resolver requires cooperation 210 from a legacy forwarder (e.g. for marking certain queries), one 211 solution is for the upstream resolver to choose not to deploy DDR 212 until all cooperating forwarders have been upgraded. Alternatively, 213 each legacy forwarder can block "resolver.arpa" as described above. 215 5. Privacy Considerations 217 The conservative validation policy results in no encryption when a 218 legacy DNS forwarder is present. This leaves the user's query 219 activity vulnerable to passive monitoring [RFC7258], either on the 220 local network or between the user and the upstream resolver. 222 The relaxed validation policy allows the use of encrypted transport 223 in these configurations, reducing exposure to a passive surveillance 224 adversary. 226 6. Security Considerations 228 When the client uses the conservative validation policy described in 229 [DDR], and a DDR-enabled resolver is identified by a private IP 230 address, the client can establish a secure DDR connection only in the 231 absence of an active attacker. An on-path attacker can impersonate 232 the resolver and intercept all queries, by preventing the DDR upgrade 233 or advertising their own DDR endpoint. 235 These basic security properties also apply if the client uses the 236 relaxed validation policy described in Section 3. Nonetheless, there 237 are some subtle but important differences in the security properties 238 of these two policies. 240 6.1. Transient attackers 242 With the conservative validation policy, a transient on-path attacker 243 can only intercept queries for the duration of their active presence 244 on the network, because the client will only send queries to the 245 original (private) server IP address. 247 With the relaxed validation behavior, a transient on-path attacker 248 could implant a long-lived DDR response in the client's cache, 249 directing its queries to an attacker-controlled server on the public 250 internet. This would allow the attack to continue long after the 251 attacker has left the network. 253 Solving or mitigating this attack is of great importance for the 254 user's security. 256 6.1.1. Solution: DNR 258 This attack does not apply if the client and network implement 259 support for Discovery of Network-designated Resolvers, as that 260 mechanism takes precedence over DDR (see Section 3.2 of [DNR]). 262 6.1.2. Mitigation: Frequent refresh 264 The client can choose to refresh the DDR record arbitrarily 265 frequently, e.g. by limiting the TTL. For example, by limiting the 266 TTL to 5 minutes, a client could ensure that any attacker can 267 continue to monitor queries for at most 5 minutes after they have 268 left the local network. 270 6.1.3. Mitigation: Resolver reputation 272 A relaxed-validation client might choose to accept a potential cross- 273 forwarder upgrade only if the designated encrypted resolver has 274 sufficient reputation, according to some proprietary reputation 275 scheme (e.g. a locally stored list of respectable resolvers). This 276 limits the ability of a DDR forgery attack to cause harm. 278 Major DoH client implementations already include lists of known 279 resolvers [CHROME-DOH][MICROSOFT-DOH][MOZILLA-TRR]. 281 6.2. Forensic logging 283 6.2.1. Network-layer logging 285 With the conservative validation policy, a random sample of IP 286 packets is likely sufficient for manual retrospective detection of an 287 active attack. 289 With the relaxed validation policy, forensic logs must capture a 290 specific packet (the attacker's DDR designation response) to enable 291 retrospective detection. 293 6.2.1.1. Mitigation: Log all DDR responses 295 Network-layer forensic logs that are not integrated with the resolver 296 can enable detection of these attacks by logging all DDR responses, 297 or more generally all DNS responses. This makes retrospective attack 298 detection straightforward, as the attacker's DDR response will 299 indicate an unexpected server. 301 6.2.2. DNS-layer logging 303 DNS-layer forensic logging conducted by a legacy DNS forwarder would 304 be lost in a cross-forwarder upgrade. 306 6.2.2.1. Solution: Respond for resolver.arpa 308 Forwarders that want to observe all queries from relaxed validation 309 clients will have to synthesize their own response for resolver.arpa, 310 either implementing DDR or disabling it. 312 7. Compatibility Considerations 314 Using DDR with legacy DNS forwarders also raises several potential 315 concerns related to loss of existing network services. 317 7.1. Split-horizon namespaces 319 Some network resolvers contain additional names that are not 320 resolvable in the global DNS. If these local resolvers are also 321 legacy DNS forwarders, a client that performs a cross-forwarder 322 upgrade might lose access to these local names. 324 7.1.1. Mitigation: NXDOMAIN Fallback 326 In "NXDOMAIN Fallback", the client repeats a query to the unencrypted 327 resolver if the encrypted resolver returns NXDOMAIN. This allows the 328 resolution of local names, provided they do not collide with globally 329 resolvable names (as required by [RFC2826]). 331 This is similar to the fallback behavior currently deployed in 332 Mozilla Firefox [FIREFOX-FALLBACK]. 334 NXDOMAIN Fallback results in slight changes to the security and 335 privacy properties of encrypted DNS. Queries for nonexistent names 336 no longer have protection against a local passive adversary, and 337 local names are revealed to the upstream resolver. 339 NXDOMAIN Fallback is only applicable when a legacy DNS forwarder 340 might be present, i.e. the unencrypted resolver has a private IP 341 address, and the encrypted resolver has a different IP address. In 342 the other DDR configurations, any local names are expected to resolve 343 similarly on both resolvers. 345 7.2. Interposable domains 347 An "interposable domain" is a domain whose owner deliberately allows 348 resolvers to forge certain responses. This arrangement is most 349 common for search engines, which often support a configuration where 350 resolvers forge a CNAME record to direct all clients to a child- 351 appropriate instance of the search engine 352 [DUCK-CNAME][BING-CNAME][GOOGLE-CNAME]. 354 Future deployments of interposable domains can instruct 355 administrators to enable or disable DDR when adding the forged 356 record, but forged records in legacy DNS forwarders could be lost due 357 to a cross-forwarder upgrade. 359 7.2.1. Mitigation: Exemption list 361 There are a small number of pre-existing interposable domains, 362 largely of interest only to web browsers. Clients can maintain a 363 list of relevant interposable domains and resolve them only via the 364 network's resolver. 366 7.3. Caching 368 Some legacy DNS forwarders also provide a shared cache for all 369 network users. Cross-forwarder upgrades will bypass this cache, 370 resulting in slower DNS resolution. 372 7.3.1. Mitigation: Stub caches 374 Clients can compensate partially for any loss of shared caching by 375 implementing local DNS caches. This mitigation is already widely 376 deployed in browsers and operating systems. 378 7.4. General mitigation: User controls 380 For these and other compatibility concerns, a possible mitigation is 381 to provide users or administrators with the ability to control 382 whether DDR is used with legacy forwarders. For example, this 383 control could be provided via a general preference, or via a 384 notification upon discovering a new upstream resolver. 386 8. Informative References 388 [BING-CNAME] 389 "Block adult content with SafeSearch - Map at a network 390 level", n.d., . 393 [CHROME-DOH] 394 "DoH providers: criteria, process for Chrome", n.d., 395 . 398 [DDR] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. 399 Jensen, "Discovery of Designated Resolvers", Work in 400 Progress, Internet-Draft, draft-ietf-add-ddr-03, 1 October 401 2021, . 404 [DNR] Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. 405 Jensen, "DHCP and Router Advertisement Options for the 406 Discovery of Network-designated Resolvers (DNR)", Work in 407 Progress, Internet-Draft, draft-ietf-add-dnr-02, 17 May 408 2021, . 411 [DUCK-CNAME] 412 "Force Safe Search at a Network Level", n.d., 413 . 416 [FIREFOX-FALLBACK] 417 "About our rollout of DNS over HTTPS", n.d., 418 . 421 [GOOGLE-CNAME] 422 "Keep SafeSearch turned on for your school, workplace, or 423 home network", n.d., 424 . 427 [MICROSOFT-DOH] 428 "Determine which DoH servers are on the known server 429 list", n.d., . 433 [MOZILLA-CANARY] 434 "Canary domain - use-application-dns.net", n.d., 435 . 438 [MOZILLA-TRR] 439 "Mozilla Policy Requirements for DNS over HTTPs Partners", 440 n.d., . 444 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 445 Communication Layers", STD 3, RFC 1122, 446 DOI 10.17487/RFC1122, October 1989, 447 . 449 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 450 J., and E. Lear, "Address Allocation for Private 451 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 452 February 1996, . 454 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 455 Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 456 2000, . 458 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 459 Configuration of IPv4 Link-Local Addresses", RFC 3927, 460 DOI 10.17487/RFC3927, May 2005, 461 . 463 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 464 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 465 . 467 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 468 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 469 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 470 2012, . 472 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 473 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 474 2014, . 476 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 477 and P. Hoffman, "Specification for DNS over Transport 478 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 479 2016, . 481 Acknowledgments 483 Thanks to Anthony Lieuallen and Eric Orth for early reviews. 485 Authors' Addresses 487 Benjamin Schwartz 488 Google LLC 490 Email: bemasc@google.com 492 Chris Box 493 BT 495 Email: chris.box@bt.com