idnits 2.17.1 draft-fhllr-dnsop-dohoperator-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 2, 2020) is 1271 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop A. Fidler 3 Internet-Draft BT plc 4 Intended status: Informational B. Hubert 5 Expires: May 6, 2021 OpenXchange 6 J. Livingood 7 Comcast 8 J. Reid 9 RTFM llp 10 N. Leymann 11 Deutsche Telekom AG 12 November 2, 2020 14 DNS over HTTPS (DoH) Considerations for Operator Networks 15 draft-fhllr-dnsop-dohoperator-00 17 Abstract 19 The introduction of DNS over HTTPS (DoH), defined in RFC8484, 20 presents a number of challenges to network operators. These are 21 described in this document. The objective is to document the problem 22 space and make suggestions that could help inform network operators 23 on how to take account of DoH deployment. This document also 24 identifies topics that may require further analysis. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 6, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Contrasting DoH and Conventional DNS . . . . . . . . . . . . 3 63 4. Regulatory and Policy Considerations . . . . . . . . . . . . 4 64 4.1. Local Policy Constraints . . . . . . . . . . . . . . . . 5 65 4.2. Regulatory and Legal Impacts . . . . . . . . . . . . . . 5 66 4.3. Regulatory Constraints . . . . . . . . . . . . . . . . . 6 67 5. Network Operations . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. Impact on DNS query logging . . . . . . . . . . . . . . . 6 69 5.2. CDN endpoint selection . . . . . . . . . . . . . . . . . 6 70 5.3. Redirection for captive portals . . . . . . . . . . . . . 7 71 5.4. Managed network services . . . . . . . . . . . . . . . . 7 72 5.5. Resolver capacity management . . . . . . . . . . . . . . 7 73 5.6. Discovery considerations . . . . . . . . . . . . . . . . 8 74 5.7. Failure recovery . . . . . . . . . . . . . . . . . . . . 8 75 5.8. Impact on Network Address Translation . . . . . . . . . . 9 76 5.9. Load balancing and failover . . . . . . . . . . . . . . . 9 77 6. User Support . . . . . . . . . . . . . . . . . . . . . . . . 9 78 7. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 12 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 10. Human Rights Considerations . . . . . . . . . . . . . . . . . 15 82 11. Open Issues for Further Study . . . . . . . . . . . . . . . . 15 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 14.2. Informative References . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 Traditional DNS traffic between stub resolvers, recursive servers and 93 authoritative servers is not encrypted. This can pose a privacy 94 challenge for Internet users, because their access to named network 95 resources can potentially be tracked through their DNS queries. In 96 principle, any network element along the path between the user and 97 resolving or authoritative servers could observe this unencrypted 98 traffic. DoT (DNS over TLS) [RFC7858] is one proposal for providing 99 privacy of DNS queries and DNS over HTTPS (DoH) [RFC8484] is another. 100 Both DoH and DoT encrypt the communications between the end client 101 (user) and recursive resolver. Plaintext DNS traffic between 102 recursive and authoritative servers is generally less of a privacy 103 concern because it usually does not contain information such as the 104 source address of the initial query that could identify the end 105 client. 107 2. Terminology 109 DoH Server: A server supporting the DNS over HTTPS is called a "DoH 110 server" to differentiate it from a "DNS server" (one that only 111 provides DNS service over one or more of the other transport 112 protocols standardised for DNS). Similarly, a client that supports 113 the DNS over HTTPS is called a "DoH client". 115 Do53: DNS over port 53 - conventional plaintext DNS. Do53 server and 116 Do53 client are the respective terms for a server or client that uses 117 conventional port 53 DNS. 119 Operator: A large Internet service provider, typically a cable 120 company or fixed/mobile telco with a national or international 121 network. 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 3. Contrasting DoH and Conventional DNS 129 With conventional DNS (Do53), using UDP or TCP port 53, most users 130 are assigned the IP addresses of several recursive resolvers via DHCP 131 or similar network bootstrapping mechanism. These are usually the IP 132 addresses of recursive resolvers that are administered by the network 133 operator. Although there is currently no equivalent to this for DoH, 134 the ADD Working Group is developing solutions for DoH server 135 discovery. 137 Users sometimes also change to third-party recursive resolvers. In 138 some cases, they may even operate their own local resolver. It is 139 not yet clear how or if DoH will be applied in these scenarios more 140 generally. Current DoH behaviour of the most widely used web 141 browsers is documented and reasonably well understood. The same 142 cannot yet be said for operating system software: stub resolver 143 libraries and web toolkits for instance. 145 RFC 8484 defines the protocol for DNS over HTTPS (DoH). When DoH is 146 used, client and server DNS traffic is encrypted using a TLS RFC 8446 147 [RFC8446] channel, typically to port 443. DoH clients will have 148 little need for conventional DNS apart from an initial bootstrap 149 query to find the IP addresses of a suitable DoH server. In some 150 cases, this will mean the bulk of the client's DNS resolver traffic 151 bypasses an operator's DNS resolver infrastructure because that 152 traffic uses the resolver service provided by a third-party DoH 153 server. 155 When DoH is used, the traditional DNS client-server model of clients 156 making queries and waiting for a reply from a server might well 157 change. It can be expected that DoH servers will sometimes use DoH 158 opportunistically. For instance a web server could include 159 application/dns-message elements in the returned HTML data, 160 anticipating the domain names that the web browser might need to 161 resolve before rendering some web page. In this scenario, the 162 browser would not need to lookup those names with DoH or conventional 163 DNS because the relevant DNS data have already been supplied. 165 DoH is already widely implemented and deployed by browser vendors. 166 All the major web browsers support DoH. Sometimes, DoH is enabled by 167 default. In others, configuration changes are needed to get the 168 browser to use DoH instead of conventional DNS. 170 Since DoH is not yet natively supported by the most widely-used DNS 171 implementations, DoH servers may need some sort of proxy or "shim" 172 module to convert between application/dns-message elements in HTML 173 and conventional DNS queries and responses. A number of 174 organisations are already offering public DoH resolution service, 175 typically using anycast technology. Some operators have either 176 deployed or are planning to deploy DoH resolver service in their 177 networks. 179 DoH changes the current, well established business model where an end 180 user (customer) pays for Internet connectivity and recursive DNS 181 service is part of that offering from the ISP. When DoH is used, the 182 customer may be dependent on DoH servers operated by third parties 183 and have no contractual or business relationship with those 184 providers. It also cannot be assumed that these DoH servers will be 185 operating under the same policy and regulatory conditions that are 186 applied by the end user's ISP. 188 4. Regulatory and Policy Considerations 189 4.1. Local Policy Constraints 191 Operator networks often have local policy constraints which require 192 some form of DNS blocking or rewriting - for example to offer 193 customers parental controls, to restrict access to illegal content or 194 to mimimise end user exposure to malware, phishing attacks and so on. 195 These tend to be implemented by using data from threat intelligence 196 providers, usually some sort of RPZ feed that is incorporated into 197 the configuration of the operator's DNS resolver infrastructure. 199 It is not yet clear how or if this functionality can be made 200 available by DoH servers. These protective measures will be less 201 effective once DoH is used because end user DNS traffic will largely 202 bypass the operator's DNS infrastructure, rendering such content and 203 security protections useless. Some of these measures may be offered 204 by some DoH servers, but as yet there is no defined mechanism to 205 ensure that all local policy is implemented. 207 4.2. Regulatory and Legal Impacts 209 Operators can also be required to perform DNS blocking and filtering 210 or rewriting for legal reasons: handling takedown notices or 211 complying with court orders. This may also be necessary for 212 operational and/or security reasons such as dealing with botnets and 213 DDoS attacks. [CSRIC] 215 As before, it is not yet clear how or if DoH servers will provide 216 this functionality. Some of these measures may be offered by some 217 DoH servers, but there is no defined mechanism to ensure that all 218 local policy is implemented, particularly those required in certain 219 jurisdictions today. Current protective measures may be less 220 effective once DoH is used because customer DNS traffic will be able 221 to bypass the operator's DNS infrastructure. 223 Conventional recursive DNS services are generally located in the 224 country where an operator is based. Since third-party DoH service 225 providers are likely to be based and/or operated from outside those 226 local countries, different protections and regulatory considerations 227 may apply to the protection, storage and processing of user data 228 processed on those servers. Typical regulations that could apply 229 include General Data Protection Regulation (EU) 2016/679 [GDPR] and 230 the EU-US Privacy Shield Framework [USPS]. These can sometimes have 231 global scope - GDPR for instance. Overseas regulations may have 232 lower, higher or even no commitments governing such services compared 233 to those that would apply to a local operator. The potential impact 234 of these regulatory obligations with respect to DoH services is 235 unclear, including whether or not they apply or even could be applied 236 at all. 238 4.3. Regulatory Constraints 240 Logs containing individual DNS queries and the IP addresses or other 241 data correlating those queries to specific users or homes may in some 242 legal jurisdictions be considered as Personal Data or PII, Personally 243 Identifying Information. In such jurisdictions detailed DNS query 244 logs may be subject to data protection and retention regulations, or 245 other legal and/or compliance requirements. 247 Operators can also be subject to regulation or other legal 248 instruments that require DNS query logs to be retained for a certain 249 period of time and made available for law enforcement purposes as 250 needed, such as under a court order or other legal process. 252 Since DoH potentially bypasses conventional DNS resolvers on which 253 these privacy, regulatory, and legal requirements are imposed, it 254 will reduce or eliminate the potential social value of these rules, 255 and may even be viewed by some countries as a potential breach of 256 regulatory compliance (whether by ISPs, DoH server operators, or 257 others). 259 5. Network Operations 261 5.1. Impact on DNS query logging 263 Analysis of resolver query data is an important task in most operator 264 networks. This can help with traffic management, load balancing and 265 capacity planning as well as network and user security. Widespread 266 uptake of DoH will mean an operator has reduced visibility of the DNS 267 traffic in their network. Query traffic logged by traditional 268 resolving servers will be less representative (or even completely 269 unrepresentative) of the overall DNS activity in an operator's 270 network. 272 5.2. CDN endpoint selection 274 End user queries made with DoH could mean that lookups return answers 275 that are sub-optimal. i.e. directing clients to a distant CDN node 276 that is outside the operator's network instead of to the localised 277 CDN node(s) installed inside that network or directly interconnected 278 with that network. Those DNS responses would be keyed on the source 279 IP address of a resolving DoH server, possibly operated by a third 280 party, rather than an address of one of the operator's resolving DNS 281 servers or end client IP address information that those resolving 282 servers might choose to provide through the Client Subnet EDNS0 283 option RFC 7871 [RFC7871]. 285 The impact to an operator of directing clients to a distant CDN node 286 that is outside the operator's network is not only slower access to 287 resources provided by the CDN. It also incurs higher costs for the 288 operator because traffic is routed over the operator's backbone and 289 peering links rather than remaining within a part of the network that 290 is geographically or topologically close to the end-user. 292 Additionally, operators have powerful technical, operational and 293 business incentives to provide optimal user experience for their 294 customers, particularly in terms of latency and speed of Internet 295 services. This involves working with multiple CDN and content 296 providers to ensure best performance when delivering those services, 297 for example by providing Client Subnet EDNS0 option information. One 298 risk is that DoH services could be provided by operators or 299 distributors of web content who have different motivations. For 300 instance a provider of DoH service may choose to offer fast access to 301 the content that they host or distribute, but may decide not to offer 302 the geographic information of the end-user (for privacy, policy or 303 business reasons) to competing content providers/distributors. 305 5.3. Redirection for captive portals 307 Network operators also often use captive portal DNS to provide 308 customer self-service activation and related customer account 309 provisioning, billing and support activities. For example, captive 310 portal DNS is used extensively to support functions such as self- 311 service provisioning of customer owned and managed Customer Premises 312 Equipment (CPE), service support, mobile pay as you go top up and 313 access to national/regional WiFi hot spots. DoH traffic may bypass 314 these operator-supplied functions that are essential for managing the 315 network. This would significantly disrupt the manner in which 316 networks are operated and managed. 318 5.4. Managed network services 320 The provision of managed network services, for instance to corporate 321 or other enterprise clients will be affected by DoH. It could 322 negatively affect bring-your-own-device policies which might 323 introduce devices into these networks that are configured to use 324 third party DoH servers. For instance there is a risk that internal 325 domain names used extensively in such networks could leak to external 326 DoH servers, presenting obvious privacy and security issues. 328 5.5. Resolver capacity management 330 Large operator networks are likely to operate their own DoH servers 331 because of local policy or business considerations. This could mean 332 an increase in TCP-based DNS traffic to port 443 as DoH displaces 333 conventional UDP-based queries to port 53. Transitioning from a 334 primarily UDP-based service to TCP-based DoH would likely require 335 substantial network capacity enhancements to an operator's DNS 336 infrastructure. This might also require changes to existing load 337 balancing and failover architectures. Establishing a DoH service in 338 these environments would absolutely impact operational management and 339 support. 341 It is unclear how much end-user DNS traffic will migrate to DoH and 342 how quickly that happens since this will depend on the uptake of DoH- 343 capable applications. There is also uncertainty about the default 344 behaviour of these applications, for instance try DoH first then fall 345 back to conventional DNS, use DoH only, try DoH and DNS in parallel 346 and accept whichever answers first, etc. These unknowns have a 347 further obvious impact on capacity planning and network operations. 349 5.6. Discovery considerations 351 Some networks offer DNS resolution services on locally scoped 352 addresses that are not globally meaningful - for instance RFC1918 or 353 link-local addresses. This arrangement is commonly found in operator 354 and enterprise networks. Discovery of DoH servers (or other forms of 355 encrypted DNS transport) in these environments is likely to rely on 356 bootstrapping from a locally-addressed Do53 resolver to the chosen 357 DoH server. That DoH server could either be offering resolution 358 service at the same local address as the Do53 resolver, or at a 359 different, possibly global, address. Both options need to be 360 considered. In both cases the DoH server would offer a TLS 361 certificate proving ownership of a name. This name should be 362 meaningful to the end client, conveying the identity of the resolver 363 operator. However given the lack of network authentication it does 364 not currently seem possible to mandate a requirement that the name 365 has to match anything that could be present in the client's 366 configuration. 368 Many network operators use stub resolvers or proxies in CPE to handle 369 end-user DNS requests. Depending on how the network is organised, 370 these stub resolvers and proxies can either present public or private 371 IP addresses to client devices. When these CPE devices use private 372 IP addresses, it will complicate encrypted DNS discovery. 374 5.7. Failure recovery 376 It is not clear how DoH services will affect customers' approach to 377 disaster recovery and fault reporting or influence their business 378 continuity planning. For instance, if a client loses connectivity or 379 access to their chosen DoH provider(s), they may lose Internet 380 service even though they remain connected to the operator's network 381 and could otherwise use conventional DNS resolution services. It is 382 assumed, but cannot be guaranteed, that DoH-capable applications will 383 fall back to conventional DNS whenever DoH service fails. 384 Applications might however be configured to only use DoH apart from 385 an initial bootstrapping query that uses conventional DNS. 387 5.8. Impact on Network Address Translation 389 Techniques such as DNS64 [RFC6147] and NAT64 [RFC6146] are widely 390 used for devices with IPv6-only transport, particularly in mobile 391 networks to ensure continued access to parts of the Internet that are 392 IPv4-only. These generally require the operator's DNS resolver 393 server to carry out some form of IP address mapping. It is not known 394 what impact DoH will have in these environments. It is unlikely that 395 this will work with third party DoH providers because they will not 396 have information about the operator's network that would allow them 397 to map these IPv6 addresses. 399 In networks where the translator prefix is not the well-known prefix 400 defined by RFC6146, the client's use of a DoH resolver outside the 401 operator's network will prevent access to IPv4-only content, because 402 the resolver will not know the correct prefix to use in its response. 403 Even when the well-known prefix is used, the DoH resolver may not be 404 configured to correctly use it in its response. 406 5.9. Load balancing and failover 408 Operator networks make extensive use of DNS-based solutions for load 409 balancing and service failover. These might not work as expected 410 with DoH clients which bypass the operator's DNS resolver 411 infrastructure. Further operational problems may arise if stale DNS 412 data are held in a DoH client's cache. 414 6. User Support 416 o Adoption of DoH is likely to decouple DNS from the provision of 417 Internet connectivity. For most users, DNS resolution is 418 currently part of the service provided by their ISP. With DoH, 419 users can be expected to rely on DoH service providers and are 420 likely to have no business or contractual relationship with those 421 providers. 423 o Getting meaningful consent from users - how? 425 o The role of user consent and whether it is a necessary factor in 426 the processing of user data is contextual. It depends on the 427 nature of relationships between the involved parties - largely the 428 ISP, the DoH provider(s) and the end user - and how those 429 relationships were established. Prevailing legislation and 430 regulation such as GDPR can also be an important consideration, 431 albeit one that is obviously out of scope for an IETF document. 432 It is not clear whether reconfiguration of a device or moving it 433 from one network to another would constitute implied consent in a 434 legal sense. 436 o In any case, only a fraction of Internet users understand the 437 mechanics of DNS resolution, which makes obtaining informed and 438 meaningful consent difficult. Service providers should seek to 439 explain data use in a way that's understandable to most people. 440 Sustained and collective efforts by service providers to educate 441 users (policymakers, legal scholars, teachers, etc.) about the 442 Internet infrastructure to foster common understanding of these 443 issues would be helpful. 445 o How will users be able to opt in/out of DoH services? 447 o Users may want to give meaningful consent to use DNS filters. 448 Therefore, there should be an option for users to enable and 449 disable DoH with neither behaviour assumed. Such permissions 450 should also apply to DoH queries made by web-based apps using an 451 API, not just the queries directly entered by the user. When 452 users do provide consent for DoH-related data processing, the 453 architecture must also support the ability for them to withdraw 454 this consent at any time. 456 o How do users select their "trusted" DoH Provider? i.e. How is a 457 user or application supplied with a list of DoH providers? How 458 does it choose between them and what are the selection criteria? 459 Presumably these could/should be considerations for the ADD 460 Working Group. 462 o Clarification is needed on trusted certificate approach, e.g. is 463 it enforced at application rather than the kernel/operating system 464 layer? 466 o Can/should discrete apps be able to choose their own DoH server? 467 Suppose a banking app is configured to use the bank's DoH 468 provider. Can that default be over-ridden? Should it? 470 o How does a user get told about (and approve) a change of DoH 471 service for a phone/tablet when they're roaming between mobile 472 telcos or using whatever DoH service is offered in $coffeeshop? 474 o How is an operator expected to support the customer or 475 troubleshoot problems caused by accidental or intentional change 476 of DoH server? If the DoH provider deletes all their historic DoH 477 traffic, how do they support the ISP customer regarding 478 troubleshooting? 480 o How will DoH provisioning take account of existing customer 481 parental control/malware protection settings and flag the 482 consequences of selecting a new provider on these? 484 o How will browsers/applications explain DoH/DNS options to 485 customers so that they can make an informed decision, as many will 486 not appreciate what DNS is. If they select a third party DoH 487 provider, that may bypass their existing network operator's 488 content and malware protection controls. The end user will 489 presumably need to set these up again with their new DoH provider. 491 o How to explain to customers that they may need to check/contact 492 both their DoH provider(s) and network provider to resolver 493 performance and outage issues. 495 7. Provisioning 497 o If some list or registry of "trusted" DoH servers is needed, who/ 498 what is going to maintain this and manage it? What criteria and 499 procedures are needed for adding or removing entries from that 500 list? How does a DoH provider become trusted or become untrusted? 502 o What are the requirements to become a DoH trusted recursive 503 resolver? Will browsers or applications only show global or 504 application-specific DoH provider options? How can regional 505 network operators offering DoH just to their customer base be 506 supported? How will browsers and applications know which regional 507 or local options exist and which of these should and should not be 508 honoured? 510 o An industry approach for DoH discovery, trust and selection that 511 operates in an open and transparent manner is needed. This should 512 give the customer meaningful consent options. 514 o How to configure CPE and other edge devices (e.g. smartphone) to 515 use the operator's chosen DoH provider. 517 o Can/should the operator's or application's choice of DoH server be 518 overridden by the customer? 520 o How do web applications get to specify the DoH server they want? 521 If web apps get to choose the DoH server, they could be pointing 522 to a malicious server (security issue) or allowing a DNS provider 523 other than that defined by the user to see the DNS queries 524 (privacy issue). 526 o How will DoH provisioning and discovery take account of existing 527 customer parental control/malware protection settings and flag the 528 consequences of selecting a new provider on these? 530 o If a browser or other edge device can do DoH, what determines if 531 the DoH is the preferred the choice?, e.g. if CPE or set top box 532 devices also supports DNS over TLS, should DoH be an option? If 533 multiple options for DNS resolution are available, what decision 534 process is used to make the customer recommendation and how is 535 this trusted? 537 8. Privacy Concerns 539 Compared to traditional DNS, DoH offers more privacy protection 540 against passive surveillance because requests and replies are carried 541 over an encrypted channel. DoH offers an equivalent amount of 542 privacy protection against passive surveillance as DoT does because 543 both rely on TLS for their security properties. 545 Content Delivery Networks use techniques like EDNS-Client-Subnet 546 (ECS) to return DNS answers that direct a client to an optimal 547 location, for instance the CDN's node in the operator's network which 548 serves the end user. DoH has the potential to be more privacy 549 intrusive than ECS, largely because DoH is based on HTTP and can 550 leverage the rich per-user and per-device tracking that pervades the 551 web today. The implications of that are not yet well understood. 553 A DoH server will have a direct HTTPS connection to the client, 554 assuming there are no middleboxes in the path between them. That 555 could for example enable DoH servers operated by CDNs to carry out 556 much more fine-grained redirection and content delivery, perhaps even 557 on a per-user or per-user-session basis. They would be able to serve 558 content and advertisements based on the end user's choice of 559 operating system, their browser and that browser's configuration in 560 addition to the client's source IP address, web cookie data, or other 561 factors as is prevalent on the web today. 563 Global DoH providers will have access to significantly more DNS query 564 data, and therefore be able to perform richer big data analytics, 565 combining these insights with those obtained from other global 566 platforms (search engines, operating systems, browsers, ad trackers, 567 analytics services, web sites, mobile apps, payment systems, 568 e-commerce platforms, social networks, Bluetooth beacons, etc.), 569 potentially leading to a poor privacy outcome for consumers. 571 The DoH provider may adhere to different privacy policies than the 572 operator's DNS service, particularly where they are located in 573 different jurisdictions. This may lead to better or worse privacy 574 outcomes for users. 576 Operators in some jurisdictions are required to perform DNS filtering 577 functions on traditional DNS queries and responses. If this 578 functionality has to be provided using DoH, the only available option 579 may be to fully proxy the HTTPS traffic. That represents more of a 580 privacy intrusion than filtering alone. 582 It is feasible that individual applications might have the ability to 583 select their own DoH server, bypassing the system- or operator- 584 defined DoH settings. That could lead to privacy violations because 585 DoH queries get sent to an arbitrary DoH server with unknown privacy 586 policies. 588 If users have no relationship with the DoH provider handling their 589 queries, they may have limited ability to exercise data protection 590 rights (erasure, objection, complaints, etc) or to pursue remedy for 591 breaches. This may be further complicated if the provider is unknown 592 to the end user, can't be easily contacted or is located in another 593 jurisdiction. 595 9. Security Considerations 597 DoH will give new opportunities for bad actors to propagate malware, 598 spam and botnets. Once they use DoH, as some botnets have already 599 started doing for command-and-control traffic, their DNS traffic will 600 be encrypted and anonymised, making it hard to deploy countermeasures 601 to protect against and mitigate these serious security threats. This 602 is likely to have an adverse impact on cybersecurity both at a 603 network/country level as well as for end users. Use of DoH could 604 make it slower to identify DNS-based DDoS attacks, more difficult to 605 attribute patient-zero for malware infections and harder to block 606 access to botnet command-and-control nodes. A proof of concept 607 exfiltration channel tool based on DoH [GODOH] already exists and it 608 is reasonable to expect others which are much less benign will emerge 609 in the future. 611 DoH queries and responses will be intermingled with other HTTPS port 612 443 traffic. This provides good traffic flow security for the 613 client, because it's not readily clear when a DoH request or reply is 614 taking place (unlike DoT). However network analytics may fail to 615 detect when a malware implant on the client is making DoH requests, 616 which would present a security risk. 618 Security of DoH relies on the TLS session for the HTTPS connection. 619 Therefore it inherits the security guarantees that TLS provides. 620 There may be interactions between DoH and TLS, for example issues 621 arising from DoH servers handling large numbers of TLS connections to 622 DoH clients simultaneously, that have not yet been explored. 624 DNS query traffic is often made available to providers of threat 625 intelligence and reputation services. These providers typically 626 aggregate such data from many operators, process these datasets and 627 then generate whitelists and blocklists which operators can then 628 apply in their networks. DoH is likely to mean there will be a 629 reduced volume of query data readily available for this sort of 630 analysis. Overall DNS query traffic would be spread across a 631 combination of operator-run DNS resolver servers and a number of DoH 632 servers who might (or might not) make their query traffic available 633 to providers of threat intelligence and reputation services. 635 This will have two unwelcome results. First, threat intelligence and 636 reputation services will have fewer data to analyse and therefore 637 have a significantly less complete perspective of end users' DNS 638 behaviour. Second, the quality and effectiveness of the data 639 provided by threat intelligence and reputation services will be 640 materially diminished. This seems likely to reduce the security of 641 networks and users as a result. 643 Although DoH uses TLS to provides authentication and data integrity 644 of the channel between client and resolver, this does not guarantee 645 that the resolver is returning correct DNS data to the client. DoH 646 clients may need to perform DNSSEC validation to verify data received 647 from DoH servers. 649 There is a risk that internal domain names used extensively in 650 managed enterprise networks could leak to external DoH servers, 651 presenting obvious privacy and security issues. 653 DoH can be implemented within the browser, rather than the kernel or 654 an operating system library. It is not yet clear if that will make 655 endpoint-based malware detection more or less effective. 657 Browser APIs will allow web applications to make DoH queries. If 658 individual applications have the ability to select their own DoH 659 server, it is not clear if that change would only apply to DoH 660 lookups by that application or if they had broader scope. When these 661 changes over-ride system- or operator-defined DoH settings, they will 662 affect other processes running on the DoH client and effectively 663 hijack their DNS traffic by rerouting it to the application's DoH 664 provider. 666 The interactions between infrastructure using Network Address 667 Translation (NAT) [RFC3022] and DoH is unclear. In situations where 668 a third party DoH server can return security threat data back to the 669 operator of the originating network, its value is likely to be 670 diminished due to the IP address sharing inherent in using NAT. 672 10. Human Rights Considerations 674 Parental control systems relying on DNS filtering can be bypassed 675 using DoH. This may lead to increased ability of minors to access 676 restricted or otherwise inappropriate content on the Internet, 677 creating a conflict with the UN Convention on the Rights of the Child 678 [Insert Ref to actual treaty text.] 680 Using DoH to bypass local DNS filtering and provide anonymity for end 681 users is a mixed blessing. Using DoH to bypass country-based DNS 682 filtering may provide end users a way of bypassing censorship 683 mechanisms put in place by restrictive regimes. On the other hand, 684 DoH could also help criminals to evade detection by obscuring the 685 source of their attacks or botnet control nodes, while increasing the 686 commercial tracking of user activity and trade in that data. 688 In jurisdictions where DNS blocking schemes have been incorporated 689 into law, widespread deployment of DoH could encourage policy 690 approaches that are more restrictive of users' freedom of expression, 691 their ability to access information or limit the generation and 692 availability of online content. 694 11. Open Issues for Further Study 696 o DoH's reliance on TLS raises a number of concerns and unknowns. 697 These include OSCP stapling, certificate life-times, scalability 698 in managing session tickets, handling session resumption and the 699 duration of TLS sessions. The trade-offs between certificate 700 validation and session duration for possibly short-lived DoH 701 transactions are not yet well understood. These factors will need 702 careful analysis, particularly on DoH servers which get queries 703 from large numbers of DoH clients. 705 o The impact of DNS traffic migrating from UDP and port 53 to TCP 706 and port 443 needs to be modelled because of the extra packets and 707 round-trip times needed for TCP connection setup and the TLS 708 handshake: performance, capacity planning, network engineering and 709 so on. 711 o DoH can leverage the rich per-user and per-device tracking that 712 pervades the web today. Since the implications of that are not 713 yet well understood, further work in this area is needed. 715 o How DoH services will develop new functionality to overcome any 716 inherent performance impact from moving the service out of the 717 operator network. For instance, optimisations to reduce latency 718 in 3/4/5G mobile networks. 720 o Clarification is needed around ECS blocking and options to avoid 721 impacting existing network operator on-net caching strategy. 723 o What DoH service metrics will be available for users to compare 724 DoH providers? 726 o DoH discovery in networks which use private IP addresses for CPE 727 and stub resolvers or proxies could be challenging. Presumably 728 this will be addressed in the add WG. 730 12. IANA Considerations 732 This memo includes no request to IANA. 734 13. Acknowledgements 736 Fill this in later 738 14. References 740 14.1. Normative References 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, 744 DOI 10.17487/RFC2119, March 1997, 745 . 747 14.2. Informative References 749 [CSRIC] FCC, "Cybersecurity Risk Management and Best Practices", 750 . 752 [GDPR] European Union, "General Data Protection Regulation (EU) 753 2016/679", 754 . 756 [GODOH] Sensepost, "DNS exfiltration using DoH", 757 . 759 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 760 Address Translator (Traditional NAT)", RFC 3022, 761 DOI 10.17487/RFC3022, January 2001, 762 . 764 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 765 NAT64: Network Address and Protocol Translation from IPv6 766 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 767 April 2011, . 769 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 770 Beijnum, "DNS64: DNS Extensions for Network Address 771 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 772 DOI 10.17487/RFC6147, April 2011, 773 . 775 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 776 and P. Hoffman, "Specification for DNS over Transport 777 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 778 2016, . 780 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 781 Kumari, "Client Subnet in DNS Queries", RFC 7871, 782 DOI 10.17487/RFC7871, May 2016, 783 . 785 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 786 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 787 . 789 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 790 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 791 . 793 [USPS] US Secretary of Commerce, "EU-U.S. Privacy Shield 794 Framework", 795 . 797 Authors' Addresses 799 Andy Fidler 800 BT plc 801 BT Adastral Park 802 Martlesham Heath, Ipswich IP5 3RE 803 UK 805 Email: andrew.fidler@bt.com 806 Bert Hubert 807 OpenXchange 808 Rollnerstrasse 14 809 Nuremberg 90408 810 Germany 812 Email: bert.hubert@open-xchange.com 814 Jason Livingood 815 Comcast 816 1800 Arch Street 817 Philadelphia PA 19118 818 USA 820 Email: jason_livingood@comcast.com 822 Jim Reid 823 RTFM llp 824 St Andrews House 825 382 Hillington Road, Glasgow G51 4BL 826 Scotland 828 Email: jim@rfc1035.com 830 Nic Leymann 831 Deutsche Telekom AG 832 Friedrich-Ebert-Allee 140 833 Bonn 53113 834 Germany 836 Email: N.Leymann@telekom.de