idnits 2.17.00 (12 Aug 2021) /tmp/idnits58224/draft-cook-doh-discovery-trial-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 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.) == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 670 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 1918' is mentioned on line 177, but not defined == Unused Reference: 'RFC1918' is defined on line 479, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Cook 3 Internet-Draft V. Bertola 4 Intended status: Informational Open-Xchange 5 Expires: January 14, 2021 A. Fidler 6 BT plc 7 N. Leymann 8 Deutsche Telekom 9 R. Weber 10 Akamai 11 July 13, 2020 13 A Proposal for a DoH Discovery Trial 14 draft-cook-doh-discovery-trial-00 16 Abstract 18 The following document describes a proposal for a trial of an 19 experimental mechanism for the discovery of DNS-over-HTTPS resolvers 20 provided by Internet Service Providers to their customers. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 14, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 The introduction of encrypted DNS transport protocols like DoH (DNS- 57 over-HTTPS [RFC8484]) can provide additional confidentiality to 58 Internet users that need a DNS resolution service to access online 59 resources. Most end-users currently get their DNS resolution service 60 from the Internet Service Provider that also supplies them with 61 Internet access; thus, to promote a straightforward migration path 62 from unencrypted to encrypted DNS transport and to avoid the issues 63 deriving from a change of DNS provider, it would be useful to 64 establish a mechanism through which stub DNS resolvers on the user's 65 device can discover under appropriate security conditions whether the 66 local network provides a DoH resolver, and if so, start using it 67 automatically. This DoH deployment model will be referred to as 68 "same provider auto-upgrade". 70 This document describes an experimental mechanism which was developed 71 by a group of Internet Service Providers and DNS implementers for 72 that use case, based on the use of a DNS query for a special use 73 domain name. It is intended as an informational document to support 74 and encourage other parties to join the experiment. 76 2. Requirements Notation and Conventions 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 Throughout this document, values are quoted to indicate that they are 83 to be taken literally. When using these values in protocol messages, 84 the quotes MUST NOT be used as part of the value. 86 3. Rationale 88 The IETF ADD Working Group was approved by the IESG in February 2020; 89 an extract from the charter [ADD] follows: 91 "This working group will focus on discovery and selection of DNS 92 resolvers by DNS clients in a variety of networking environments, 93 including public networks, private networks, and VPNs, supporting 94 both encrypted and unencrypted resolvers. It is chartered solely to 95 develop technical mechanisms. Making any recommendations about 96 specific policies for clients or servers is out of scope." 97 To support the achievement of this technical objective, non-technical 98 considerations also come into play. There is a desire to maximise 99 the number of users that can enjoy an easy upgrade path towards DNS 100 encryption, by making it possible for customers of ISPs that deploy 101 DoH interfaces to their resolvers to get upgraded automatically. 103 The early discovery mechanisms implemented by some browsers cannot 104 cope with home networks advertising the CPE's private IP address as 105 the endpoint for the local DNS resolver, and thus would exclude the 106 fixed broadband and home mobile router customers of a significant 107 number of ISPs (including the major ones in Europe) from access to 108 this new technology, depending on their Internet access network 109 architecture and on their ease of upgrade of CPEs. 111 Additionally, in Europe regulation requires all ISPs to allow users 112 to connect to the Internet with any home router of their choice, so 113 it is not even possible for ISPs to prevent the use of home routers 114 that do not support any other DNS resolver mode than dnsmasq over a 115 private IP address. 117 Regardless of the outcome of IETF and policy discussions, it is 118 likely that any fully fledged, standard discovery protocol will take 119 a relatively long time to reach consensus. Therefore this document 120 proposes an interim solution, which combines in-band discovery with 121 out-of-band protections such as those already used by Google Chrome 122 and Microsoft Windows (i.e. pre-vetting of DoH services, plus some 123 additional protections as discussed below). 125 This solution would allow participating ISPs using DNS forwarders in 126 their CPEs to provide DoH resolver services to their users in a short 127 timeframe, as long as they used clients (browsers and operating 128 systems) that participate in this trial. 130 The proposed solution is described in the following section. 132 4. The Proposed DoH Discovery Trial 134 4.1. How ISPs Join the Trial 136 Out-of-band (e.g. through the already established process, or through 137 direct contact at industry venues such as EDDI [EDDI]), ISPs make it 138 known that they would like client vendors to discover their DoH 139 service, but have a significant proportion of users who are using 140 CPEs which act as forwarders. 142 Each participating vendor, depending on their own security policies, 143 decides if they are fine with an open DNS-based discovery of the 144 local resolver, or if they want to reduce the potential attack 145 surface by restricting the resolvers that the local network can 146 advertise. Section 5.2. describes the security implications of such 147 a choice. 149 In the latter case, participating ISPs, regardless of whether they 150 plan to offer public DoH services, guarantee that they (also) offer a 151 DoH service on a URI which is closed, i.e. only accessible from their 152 own network and not from the Internet, and whose hostname is located 153 within a domain name owned by the ISP; this is the DoH service that 154 can be enrolled in the program for vendors that require such 155 restriction. We will refer to these DoH services as "closed 156 resolvers". 158 This restriction prevents malicious actors from switching a user's 159 DNS resolution to an off-net DNS resolver which is also a trial 160 participant. (However it does not prevent switching from an off-net 161 to an on-net resolver; see section 5). It is up to each DoH client 162 vendor whether they choose to validate (once or continuously) such a 163 guarantee. 165 The ISPs then provide the vendors with the URI(s) of their 166 (optionally closed) DoH service(s). The URI must contain an FQDN; IP 167 addresses are not acceptable. These URIs are added to a list 168 maintained by the DoH client vendor. For the purposes of this 169 document, we shall call this list the "whitelist" of DoH servers 170 corresponding to ISP resolvers reached via CPEs; it could be a 171 different list from the list of public DoH services used by the 172 current auto-upgrade mechanisms. 174 4.2. Proposed DoH Resolver Discovery Logic 176 This process only starts if the configured Do53 resolver is a private 177 ([RFC 1918]) IPv4 or IPv6 link local or unique local address. The 178 auto-upgrade of resolvers with public IP addresses is outside of the 179 scope of this document, though participating vendors, if they want, 180 can use this mechanism for that purpose as well. 182 The client performs over Do53 (traditional DNS) a TXT record lookup 183 for dohresolver.arpa, a specifically chosen special use domain name 184 (SUDN) [RFC6761]. Eventually, if this mechanism gains adoption, it 185 may be appropriate to register this name with IANA, but we do not 186 anticipate any problems using it on an interim basis, since it is 187 restricted to specific resolvers and does not affect the wider DNS or 188 the arpa TLD. Also, it would be easy to move to any other SUDN that 189 might be standardized by the IETF. 191 The resolver is configured to respond to that SUDN with a TXT record 192 containing the URI template of the DoH service. 194 If the Do53 response is anything other than a TXT answer, the 195 discovery is terminated. As a note, some browser makers reported 196 that they sometimes have difficulties with performing lookups on DNS 197 records other than A/AAAA. If CPE routinely filter/drop TXT record 198 lookups, then this approach will not work. To our knowledge, none of 199 the CPE of the ISPs providing data for this document do any 200 modification or filtering of TXT records, and common forwarding 201 software such as dnsmasq does not appear to have issues with 202 arbitrary RRs. Any more facts on this topic would be useful. 204 In the event of no response being received, the client should decide 205 its own retry policy for the dohresolver.arpa query, but we recommend 206 one or more retries are performed to mitigate packet loss or 207 temporary high load. 209 In the event of a successful response, the client - if so desires - 210 can check whether the URI in the response matches one of the 211 (optionally closed) DoH URIs that have been added to the "whitelist", 212 and discard it if not. 214 In the event of a successful response which points to an acceptable 215 DoH resolver, it is up to the DoH client vendor what happens next, 216 for example: 218 o Auto-upgrade takes place - i.e. connection is attempted to that 219 URI. Assuming that certificate validation and TLS handshake 220 succeeds etc., resolution switches to the DoH service, otherwise 221 the client continues to use the Do53 service. 223 o The user is presented with a dialog asking them if they'd like to 224 use the newly discovered DoH server. If they accept, then 225 connection proceeds as above. 227 o The DoH server is added to a list of manually selectable DoH 228 servers. 230 o Any other suitable logic, e.g. ignoring the response for policy 231 reasons. 233 The DoH client should respect the TTL of the TXT record returned, and 234 perform a new DNS lookup upon expiry. 236 4.3. Effect on Possible Use Cases 238 The basic policy principle for the existing auto-upgrade methods is 239 to avoid changing the resolver that the user has chosen either 240 explicitly (i.e. through manual configuration) or implicitly (e.g. 241 via DHCP). 243 This logic attempts to preserve that as far as practically possible, 244 through use of the TXT record lookup; the lookup will only return a 245 valid answer if the resolver being used has actively created an 246 authoritative TXT record for the dohresolver.arpa domain. This 247 assumes no malicious actors; see section 5 for security 248 considerations. 250 We will now discuss the impact of running such an experiment in real 251 world use cases, showing the behaviour that will occur for customers 252 of participating ISPs using participating clients if the DoH client 253 follows the logic described in this proposal. The four possible 254 scenarios for a consumer setup cover all the possible variations of 255 resolver/forwarder configuration and downstream resolver. If either 256 the ISP or the client does not participate in the experiment, no 257 auto-upgrade will ever happen. 259 This is the effect of the proposed logic in the different scenarios: 261 1. The user is using an ISP-supplied CPE, which forwards Do53 262 traffic to the ISP's Do53 resolver. The ISP's Do53 resolver will 263 return a TXT record for dohresolver.arpa, and thus auto-upgrade 264 will take place. The client will then bypass the forwarder, 265 directing queries via DoH directly to the ISP's resolver. 267 2. The user manually configured a local DNS forwarder themselves 268 (e.g. an off-the-shelf CPE, or they run dnsmasq on a local 269 server) to forward queries to their local ISP resolver. This 270 resolver will return a TXT record for dohresolver.arpa, and thus 271 auto-upgrade will take place, bypassing the forwarder, exactly 272 like in the previous case. 274 3. The user has manually configured a local DNS forwarder themselves 275 (e.g. an off-the-shelf CPE, or they have modified the ISP- 276 provided CPE) to forward to a resolver that is not the ISP 277 resolver, e.g. 1.1.1.1 or 9.9.9.9. These resolvers will return 278 NXDOMAIN for dohresolver.arpa, and thus no auto-upgrade will take 279 place. 281 4. The user has manually configured a local DNS resolver themselves 282 (e.g. Raspberry PI or similar). This resolver will return 283 NXDOMAIN for dohresolver.arpa, and thus no auto-upgrade will take 284 place. 286 From the DoH client's perspective, all four scenarios are the same 287 (i.e. the system resolver has a RFC1918 IPv4 or IPv6 link local or 288 unique local address), and whether that resolver was configured via 289 DHCP or manually would not appear to matter that much. Scenarios 3 290 and 4 can be discounted because no action takes place, however 291 scenarios 1 and 2 do have the effect of bypassing the forwarder. 293 There is a semantic difference between scenarios 1 and 2; in scenario 294 2 the user may have configured a forwarder deliberately, for example 295 to do filtering, caching, logging or innumerable other reasons. For 296 that reason, DoH client vendors need to consider whether the above 297 scenarios, (or any additional scenarios not considered above), 298 justify asking for the user's consent to the upgrade to DoH directly 299 to the ISP resolver (and thus bypassing any intermediate forwarders). 301 Moreover, in cases 3 and 4 it would be easy for the operator of the 302 alternative resolver (whether it is another DNS operator, as in case 303 3, or the user themselves, as in case 4) to also allow auto-upgrade 304 to DoH of the connection, simply by configuring their own resolver to 305 reply to the query for dohresolver.arpa. However, if the client 306 vendor chooses to restrict the auto-upgrade mechanism only to 307 whitelisted URIs, then these other operators would need to also join 308 the experiment; in case 3, this could be made impossible by the 309 restriction itself, as by definition the resolver in this case is an 310 "open" one, and the vendor would need to partially lift the 311 restriction and accept known open DoH resolvers from a separate 312 whitelist; in case 4, this could be made impossible by the non- 313 technical requirements of the procedure for joining. 315 5. Security Considerations 317 5.1. Existing Auto-Upgrade Mechanisms 319 The security objective for current same-provider auto-upgrade 320 mechanisms is to ensure that the client is talking to the same 321 resolver operator as before, but now over DoH. On-path attackers 322 have no way to influence this, since the mechanism is based on the 323 client knowing the public IP address of the existing resolver and a 324 pre-configured URI template for the auto-upgrade DoH resolver for 325 that IP address. 327 5.2. Current Proposal 329 This proposal does not use the same threat model as the existing 330 auto-upgrade solution. The differences are discussed below. 332 On-path attackers could perform a downgrade attack. However, given 333 that current auto-upgrade mechanisms do not work for users with 334 forwarders in their CPE, such a downgrade attack would result in the 335 same situation as currently, i.e. the client would continue to use 336 Do53. However, given this threat, the upgrade to DoH can only be 337 considered as opportunistic security. 339 On-path attackers could change the discovery response from that 340 returned by the actual configured resolver. There are two scenarios 341 that need to be considered, depending on the vendor's policy. 343 If the DoH client vendor enforces the "closed resolver" restriction, 344 then the following applies: 346 o Given that the client will only accept auto-upgrade via discovery 347 to a "closed resolver", there is only one resolver that will be 348 accepted by the client via the discovery mechanism - the DoH 349 resolver offered by the user's ISP. (This assumes that the ISP is 350 diligent about ensuring their resolver is actually closed - this 351 could be verified periodically by the vendors). 353 o There exists a risk that an on-path attacker could redirect a user 354 from a manually selected resolver (configured manually by the user 355 on the CPE/forwarder) to the resolver provided by the local ISP. 356 This would have the effect of moving the user from a resolver that 357 they did select (e.g. 9.9.9.9) to one they did not select. Such a 358 risk is not mitigated by this proposal. Note that this risk 359 exists only when there is an on-path attacker, since the discovery 360 query happens via DNS and thus goes to the resolver originally 361 chosen by the user. 363 If the DoH client vendor does not enforce the "closed resolver" 364 restriction, then the following applies. An on-path attacker could 365 redirect a user from a manually selected resolver (configured 366 manually by the user on the CPE/forwarder) to any resolver on the 367 "whitelist" of DoH servers. This would have the effect of moving the 368 user from a resolver that they did select to one they did not select. 369 Such a risk is not mitigated by this proposal. Note that this risk 370 exists only when there is an on-path attacker, since the discovery 371 query happens via DNS and thus goes to the resolver originally chosen 372 by the user. 374 In both of the above use cases, the only possible end result of a 375 successful attack aimed at changing resolvers is that a user has 376 moved from an insecure Do53 service whose results are controlled by a 377 malicious on-path attacker, to a secure DoH service which is on the 378 DoH client's "whitelist". The on-path attacker has only succeeded in 379 moving the user to a vendor-verified resolver over which they have no 380 control, and which they cannot use for further attacks; as long as 381 the vendor's whitelisting process is secure, an attacker wishing to 382 gain control of the user's DNS resolution process for further steps, 383 e.g. to redirect the user's Web requests to a phishing page, would 384 not be able to do so through this attack. This would apply even if 385 the new DoH resolver were open, as long as it is on (the same or 386 another) vendor-verified whitelist. However, the user has still 387 moved to a resolver operated by a different organization which is 388 almost certainly not what the user "wanted"; hence the possible need 389 for user confirmation. 391 The security assumptions regarding the "closed resolvers" above are 392 predicated on the participating ISPs performing the appropriate 393 actions to "close" their resolver(s) to the public internet, thus 394 making them only available to customers on their network. DoH client 395 vendors relying on the security assumptions provided by this may wish 396 to make periodic checks (see section 6) to ensure that listed DoH 397 resolvers are indeed not accessible from the public internet, 398 otherwise new attacks would be possible such as an on-path attacker 399 redirecting a user from their currently selected resolver to the 400 resolver of another participating ISP. 402 In the end, vendors that adopt the approach of vetting and 403 whitelisting DoH resolvers before allowing users to auto-upgrade to 404 them will always enjoy a certain degree of reassurance on the 405 legitimacy of those resolvers (though at the expense of excluding the 406 users of other DoH resolvers, including self-managed resolvers that 407 people may install on their home networks, from automatic upgrade). 409 Without the additional "closed resolver" restriction, an attacker may 410 succeed in redirecting the user to any of the whitelisted DoH 411 services, while with that additional restriction, an attacker may 412 only succeed in redirecting the user to the ISP's own closed DoH 413 service, if the user is not already using it. Whether this gain in 414 security is worth the additional organizational complexity is for 415 each vendor to consider; we expect that running this experiment could 416 also allow to evaluate how useful that additional restriction could 417 be in practice. 419 6. Implications for Vendors 421 The experiment requires participating vendors to change their current 422 implementation of the auto-upgrade mechanism and add the logic 423 described. 425 For DoH client vendors enforcing the "closed resolver" restriction, 426 some additional vetting and active checking of "auto-upgrade" DoH 427 providers would be necessary, to ensure that ISP resolvers are indeed 428 "closed" and only accessible to customers on their own networks, as 429 assumed in Section 5 above. This could take the form of periodic 430 attempts to connect to all the DoH URIs on the "whitelist" from a 431 variety of locations known to be outside of any service provider 432 networks. It would be up to the organisation responsible for the DoH 433 client to decide how stringent this check should be. For example, it 434 may involve automated weekly checks, and alerts to ISPs whose 435 resolvers do not meet the required standards. 437 DoH client vendors who also support the "auto-upgrade based on public 438 resolver IP" logic need to maintain two "whitelists"; DoH servers 439 could of course be on both lists, or both lists could be merged into 440 one with additional parameters for each featured resolver, as 441 preferred. 443 7. Acknowledgements 445 This document is the product of an informal group of experts 446 including the following people: 448 Alister Winfield, Sky 450 Andrew Campling, 419 Consulting 452 Andy Fidler, BT plc 454 Chris Box, BT plc 456 Gianpaolo Scalone, Vodafone 458 Neil Cook, Open-Xchange 460 Nic Leymann, Deutsche Telekom 462 Norman Kowalewski, Deutsche Telekom 464 Ralf Weber, Akamai 466 Vittorio Bertola, Open-Xchange 468 The authors would like to thank Kenji Baheux and Eric Orth (Google) 469 and Tommy Jensen (Microsoft) for their feedback and suggestions. 471 8. References 473 8.1. Normative References 475 [ADD] IETF, "Adaptive DNS Discovery (ADD) Working Group", 476 February 2020, 477 . 479 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 480 and E. Lear, "Address Allocation for Private Internets", 481 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 482 . 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, 486 DOI 10.17487/RFC2119, March 1997, 487 . 489 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 490 RFC 6761, DOI 10.17487/RFC6761, February 2013, 491 . 493 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 494 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 495 . 497 8.2. Informative References 499 [EDDI] EDDI, "Encrypted DNS Deployment Initiative", July 2020, 500 . 502 Authors' Addresses 504 Neil Cook 505 Open-Xchange Ltd 506 7 Gerard Street 507 Ashton-in-Makerfield, Wigan, Greater Manchester WN4 9AG 508 United Kingdom 510 Email: neil.cook@noware.co.uk 511 URI: https://www.open-xchange.com/ 513 Vittorio Bertola 514 Open-Xchange Srl 515 Via Treviso 12 516 Torino 10144 517 Italy 519 Email: vittorio.bertola@open-xchange.com 520 URI: https://www.open-xchange.com/ 521 Andy Fidler 522 BT plc 523 BT Adastral Park 524 Martlesham Heath, Ipswich IP5 3RE 525 United Kingdom 527 Email: andrew.fidler@bt.com 528 URI: https://www.bt.com/ 530 Nicolai Leymann 531 Deutsche Telekom AG 532 Friedrich-Ebert-Allee 140 533 Bonn 53113 534 Germany 536 Email: N.Leymann@telekom.de 537 URI: https://www.telekom.com/ 539 Ralf Weber 540 Akamai Technologies GmbH 541 Parkring 20-22 542 Garching 85748 543 Germany 545 Email: ralf.weber@akamai.com 546 URI: https://www.akamai.com/