idnits 2.17.1 draft-reid-doh-operator-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 (March 10, 2019) is 1846 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 DoH A. Fidler 3 Internet-Draft BT plc 4 Intended status: Informational B. Hubert 5 Expires: September 11, 2019 OpenXchange 6 J. Livingood 7 Comcast 8 J. Reid 9 RTFM llp 10 N. Leymann 11 Deutsche Telekom AG 12 March 10, 2019 14 DNS over HTTPS (DoH) Considerations for Operator Networks 15 draft-reid-doh-operator-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 September 11, 2019. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . 4 65 4.2. Regulatory and Legal Impacts . . . . . . . . . . . . . . 5 66 4.3. Regulatory Constraints . . . . . . . . . . . . . . . . . 5 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. Failure recovery . . . . . . . . . . . . . . . . . . . . 8 74 5.7. Impact on Network Address Translation . . . . . . . . . . 8 75 5.8. Load balancing and failover . . . . . . . . . . . . . . . 8 76 6. User Support . . . . . . . . . . . . . . . . . . . . . . . . 8 77 7. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8. Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 11 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 10. Human Rights Considerations . . . . . . . . . . . . . . . . . 13 81 11. Open Issues for Further Study . . . . . . . . . . . . . . . . 14 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 86 14.2. Informative References . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 Traditional DNS traffic between stub resolvers, recursive servers and 92 authoritative servers is not encrypted. This can pose a privacy 93 challenge for Internet users, because their access to named network 94 resources can potentially be tracked through their DNS queries. In 95 principle, any network element along the path between the user and 96 resolving or authoritative servers could observe this unencrypted 97 traffic. DoT (DNS over TLS) [RFC7858] is one proposal for providing 98 privacy of DNS queries and DNS over HTTPS (DoH) [RFC8484] is another. 99 Both DoH and DoT encrypt the communications between the end client 100 (user) and recursive resolver. Plaintext DNS traffic between 101 recursive and authoritative servers is generally less of a privacy 102 concern because it usually does not contain information such as the 103 source address of the initial query that could identify the end 104 client. 106 2. Terminology 108 DoH Server: A server supporting the DNS over HTTPS is called a "DoH 109 server" to differentiate it from a "DNS server" (one that only 110 provides DNS service over one or more of the other transport 111 protocols standardised for DNS). Similarly, a client that supports 112 the DNS over HTTPS is called a "DoH client". 114 Operator: A large Internet service provider, typically a cable 115 company or fixed/mobile telco with a national or international 116 network. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 3. Contrasting DoH and Conventional DNS 124 With conventional DNS today, using UDP or TCP port 53, most users are 125 assigned the IP addresses of several recursive resolvers via DHCP or 126 similar network bootstrapping mechanism. These are usually the IP 127 addresses of recursive resolvers that are administered by the network 128 operator. There is currently no equivalent to this for DoH. Users 129 sometimes also change to third-party recursive resolvers. In some 130 cases, they may even operate their own local resolver. It is not yet 131 clear how or if DoH will offer these possibilities. 133 RFC 8484 defines the protocol for DNS over HTTPS (DoH). When DoH is 134 used, client and server DNS traffic is encrypted using a TLS RFC 8446 135 [RFC8446] channel, typically to port 443. DoH clients will have 136 little need for conventional DNS apart from an initial bootstrap 137 query to find the IP addresses of a suitable DoH server. This will 138 mean the bulk of their DNS resolver traffic would bypass an 139 operator's DNS resolver infrastructure because that traffic will make 140 use of the resolver service provided by the DoH server. 142 When DoH is used, the traditional DNS client-server model of clients 143 making queries and waiting for a reply from a server might well 144 change. It can be expected that DoH servers will sometimes use DoH 145 opportunistically. For instance a web server could include 146 application/dns-message elements in the returned HTML data, 147 anticipating the domain names that the web browser might need to 148 resolve before rendering some web page. In this case, the client 149 would not need to lookup those names with DoH or conventional DNS 150 because the relevant DNS data have already been supplied. 152 It is likely that DoH will be widely implemented and deployed by 153 browser vendors and DNS providers. Some deployment has already taken 154 place. 156 Adoption of DoH is expected to be driven by browser vendors adding 157 DoH support in future releases of their software. They may even make 158 DoH the default for browser DNS lookups rather than conventional port 159 53 queries. 161 DoH changes the current, well established business model where an end 162 user (customer) pays for Internet connectivity and recursive DNS 163 service is part of that offering from the ISP. When DoH is used, the 164 customer will probably be dependent on DoH servers operated by third 165 parties and have no contractual or business relationship with those 166 providers. It also cannot be assumed that these DoH servers will be 167 operating under the same policy and regulatory conditions that are 168 applied by the end user's ISP. 170 4. Regulatory and Policy Considerations 172 4.1. Local Policy Constraints 174 Operator networks often have local policy constraints which require 175 some form of DNS blocking or rewriting - for example to offer 176 customers parental controls, to restrict access to illegal content or 177 to mimimise end user exposure to malware, phishing attacks and so on. 178 These tend to be implemented by using data from threat intelligence 179 providers, usually some sort of RPZ feed that is incorporated into 180 the configuration of the operator's DNS resolver infrastructure. 182 It is not yet clear how or if this functionality can be made 183 available by DoH servers. These protective measures will be less 184 effective once DoH is used because end user DNS traffic will largely 185 bypass the operator's DNS infrastructure, rendering such content and 186 security protections useless. Some of these measures may be offered 187 by some DoH servers, but as yet there is no defined mechanism to 188 ensure that all local policy is implemented. 190 4.2. Regulatory and Legal Impacts 192 Operators can also be required to perform DNS blocking and filtering 193 or rewriting for legal reasons: handling takedown notices or 194 complying with court orders. This may also be necessary for 195 operational and/or security reasons such as dealing with botnets and 196 DDoS attacks. [CSRIC] 198 As before, it is not yet clear how or if DoH servers will provide 199 this functionality. Some of these measures may be offered by some 200 DoH servers, but there is no defined mechanism to ensure that all 201 local policy is implemented, particularly those required in certain 202 jurisdictions today. Current protective measures will be less 203 effective once DoH is used because customer DNS traffic will largely 204 bypass the operator's DNS infrastructure. 206 Conventional recursive DNS services are generally located in the 207 country where an operator is based. Since third-party DoH service 208 providers are likely to be based and/or operated from outside those 209 local countries, different protections and regulatory considerations 210 may apply to the protection, storage and processing of user data 211 processed on those servers. Typical regulations that could apply 212 include General Data Protection Regulation (EU) 2016/679 [GDPR] and 213 the EU-US Privacy Shield Framework [USPS]. These can sometimes have 214 global scope - GDPR for instance. Overseas regulations may have 215 lower, higher or even no commitments governing such services compared 216 to those that would apply to a local operator. The potential impact 217 of these regulatory obligations with respect to DoH services is 218 unclear, including whether or not they apply or even could be applied 219 at all. 221 4.3. Regulatory Constraints 223 Logs containing individual DNS queries and the IP addresses or other 224 data correlating those queries to specific users or homes may in some 225 legal jurisdictions be considered as personally identifying 226 information (PII). In such jurisdictions detailed DNS query logs may 227 be subject to data protection and retention regulations, or other 228 legal and/or compliance requirements. 230 Operators can also be subject to regulation or other legal 231 instruments that require DNS query logs to be retained for a certain 232 period of time and made available for law enforcement purposes as 233 needed, such as under a court order or other legal process. 235 Since DoH potentially bypasses conventional DNS resolvers on which 236 these privacy, regulatory, and legal requirements are imposed, it 237 will reduce or eliminate the potential social value of these rules, 238 and may even be viewed by some countries as a potential breach of 239 regulatory compliance (whether by ISPs, DoH server operators, or 240 others). 242 5. Network Operations 244 5.1. Impact on DNS query logging 246 Analysis of resolver query data is an important task in most operator 247 networks. This can help with traffic management, load balancing and 248 capacity planning as well as network and user security. Widespread 249 uptake of DoH will mean an operator has reduced visibility of the DNS 250 traffic in their network. Query traffic logged by traditional 251 resolving servers will be less representative (or even completely 252 unrepresentative) of the overall DNS activity in an operator's 253 network. 255 5.2. CDN endpoint selection 257 End user queries made with DoH could mean that lookups return answers 258 that are sub-optimal. i.e. directing clients to a distant CDN node 259 that is outside the operator's network instead of to the localised 260 CDN node(s) installed inside that network or directly interconnected 261 with that network. Those DNS responses would be keyed on the source 262 IP address of a resolving DoH server, possibly operated by a third 263 party, rather than an address of one of the operator's resolving DNS 264 servers or end client IP address information that those resolving 265 servers might choose to provide through the Client Subnet EDNS0 266 option RFC 7871 [RFC7871]. 268 The impact to an operator of directing clients to a distant CDN node 269 that is outside the operator's network is not only slower access to 270 resources provided by the CDN. It also incurs higher costs for the 271 operator because traffic is routed over the operator's backbone and 272 peering links rather than remaining within a part of the network that 273 is geographically or topologically close to the end-user. 275 Additionally, operators have powerful technical, operational and 276 business incentives to provide optimal user experience for their 277 customers, particularly in terms of latency and speed of Internet 278 services. This involves working with multiple CDN and content 279 providers to ensure best performance when delivering those services, 280 for example by providing Client Subnet EDNS0 option information. One 281 risk is that DoH services could be provided by operators or 282 distributors of web content who have different motivations. For 283 instance a provider of DoH service may choose to offer fast access to 284 the content that they host or distribute, but may decide not to offer 285 the geographic information of the end-user (for privacy, policy or 286 business reasons) to competing content providers/distributors. 288 5.3. Redirection for captive portals 290 Network operators also often use captive portal DNS to provide 291 customer self-service activation and related customer account 292 provisioning, billing and support activities. For example, captive 293 portal DNS is used extensively to support functions such as self- 294 service provisioning of customer owned and managed Customer Premises 295 Equipment (CPE), service support, mobile pay as you go top up and 296 access to national/regional WiFi hot spots. DoH traffic may bypass 297 these operator-supplied functions that are essential for managing the 298 network. This would significantly disrupt the manner in which 299 networks are operated and managed. 301 5.4. Managed network services 303 The provision of managed network services, for instance to corporate 304 or other enterprise clients will be affected by DoH. It could 305 negatively affect bring-your-own-device policies which might 306 introduce devices into these networks that are configured to use 307 third party DoH servers. For instance there is a risk that internal 308 domain names used extensively in such networks could leak to external 309 DoH servers, presenting obvious privacy and security issues. 311 5.5. Resolver capacity management 313 Large operator networks are likely to operate their own DoH servers 314 because of local policy or business considerations. This could mean 315 an increase in TCP-based DNS traffic to port 443 as DoH displaces 316 conventional UDP-based queries to port 53. Transitioning from a 317 primarily UDP-based service to TCP-based DoH would likely require 318 substantial network capacity enhancements to an operator's DNS 319 infrastructure. This might also require changes to existing load 320 balancing and failover architectures. Establishing a DoH service in 321 these environments would absolutely impact operational management and 322 support. 324 It is unclear how much end-user DNS traffic will migrate to DoH and 325 how quickly that happens since this will depend on the uptake of DoH- 326 capable applications. There is also uncertainty about the default 327 behaviour of these applications, for instance try DoH first then fall 328 back to conventional DNS, use DoH only, try DoH and DNS in parallel 329 and accept whichever answers first, etc. These unknowns have a 330 further obvious impact on capacity planning and network operations. 332 5.6. Failure recovery 334 It is not clear how DoH services will affect customers' approach to 335 disaster recovery and fault reporting or influence their business 336 continuity planning. For instance, if a client loses connectivity or 337 access to their chosen DoH provider(s), they may lose Internet 338 service even though they remain connected to the operator's network 339 and could otherwise use conventional DNS resolution services. It is 340 assumed, but cannot be guaranteed, that DoH-capable applications will 341 fall back to conventional DNS whenever DoH service fails. 342 Applications might however be configured to only use DoH apart from 343 an initial bootstrapping query that uses DNS. 345 5.7. Impact on Network Address Translation 347 Techniques such as DNS64 [RFC6147] and NAT64 [RFC6146] are widely 348 used for devices with IPv6-only transport, particularly in mobile 349 networks to ensure continued access to parts of the Internet that are 350 IPv4-only. These generally require the operator's DNS resolver 351 server to carry out some form of IP address mapping. It is not known 352 what impact DoH will have in these environments. It is unlikely that 353 this will work with third party DoH providers because they will not 354 have information about the operator's network that would allow them 355 to map these IPv6 addresses. 357 In networks where the translator prefix is not the well-known prefix 358 defined by RFC6146, the client's use of a DoH resolver outside the 359 operator's network will prevent access to IPv4-only content, because 360 the resolver will not know the correct prefix to use in its response. 361 Even when the well-known prefix is used, the DoH resolver may not be 362 configured to correctly use it in its response. 364 5.8. Load balancing and failover 366 Operator networks make extensive use of DNS-based solutions for load 367 balancing and service failover. These might not work as expected 368 with DoH clients which bypass the operator's DNS resolver 369 infrastructure. Further operational problems may arise if stale DNS 370 data are held in a DoH client's cache. 372 6. User Support 374 o Adoption of DoH is likely to decouple DNS from the provision of 375 Internet connectivity. For most users, DNS resolution is 376 currently part of the service provided by their ISP. With DoH, 377 users can be expected to rely on DoH service providers and are 378 likely to have no business or contractual relationship with those 379 providers. 381 o Getting meaningful consent from users - how? 383 o How will users be able to opt in/out of DoH services? 385 o Users may want to give meaningful consent to use DNS filters. 386 Therefore, there should be an option for users to enable and 387 disable DoH with neither behaviour assumed. Such permissions 388 should also apply to DoH queries made by web-based apps using an 389 API, not just the queries directly entered by the user. 391 o How do users select their "trusted" DoH Provider? NB This is 392 BEFORE draft-hoffman-resolver-associated-doh or whatever is used 393 by a DoH client to connect to its chosen DoH server/service. i.e. 394 How is a user or application supplied with a list of DoH 395 providers? How does it choose between them and what are the 396 selection criteria? 398 o Clarification is needed on trusted certificate approach, e.g. is 399 it enforced at application rather than the kernel/operating system 400 layer? 402 o Can/should discrete apps be able to choose their own DoH server? 403 Suppose a banking app is configured to use the bank's DoH 404 provider. Can that default be over-ridden? Should it? 406 o How does a user get told about (and approve) a change of DoH 407 service for a phone/tablet when they're roaming between mobile 408 telcos or using whatever DoH service is offered in $coffeeshop? 410 o How is an operator expected to support the customer or 411 troubleshoot problems caused by accidental or intentional change 412 of DoH server? If the DoH provider deletes all their historic DoH 413 traffic, how do they support the ISP customer regarding 414 troubleshooting? 416 o How will DoH provisioning take account of existing customer 417 parental control/malware protection settings and flag the 418 consequences of selecting a new provider on these? 420 o How will browsers/applications explain DoH/DNS options to 421 customers so that they can make an informed decision, as many will 422 not appreciate what DNS is. If they select a third party DoH 423 provider, that may bypass their existing network operator's 424 content and malware protection controls. The end user will 425 presumably need to set these up again with their new DoH provider. 427 o How to explain to customers that they may need to check/contact 428 both their DoH provider(s) and network provider to resolver 429 performance and outage issues. 431 7. Provisioning 433 o Some list or registry of "trusted" DoH servers is probably 434 necessary. Who/what is going to maintain this and manage it? 435 What criteria and procedures are needed for adding or removing 436 entries from that list? How does a DoH provider get trusted and 437 become untrusted? 439 o What are the requirements to become a DoH trusted recursive 440 resolver? Will browsers or applications only show global DoH 441 provider options? How can regional network operators offering DoH 442 just to their customer base be supported? How will browsers and 443 applications know which regional or local options exist and which 444 of these should and should not be honoured? 446 o Need an industry approach for DoH discovery, trust and selection 447 that operates in an open and transparent manner, giving the 448 customer meaningful consent options. 450 o How to configure CPE and other edge devices (e.g. smartphone) to 451 use the operator's chosen DoH provider. 453 o Can/should the operator's choice be overridden by the customer? 455 o Clients need to know the IP address of the DoH server they want to 456 use. How is this discovered, draft-hoffman-resolver-associated- 457 doh? 459 o How do web applications get to specify the DoH server they want? 460 If web apps get to choose the DoH server, they could be pointing 461 to a malicious server (security issue) or allowing a DNS provider 462 other than that defined by the user to see the DNS queries 463 (privacy issue). 465 o How will DoH provisioning take account of existing customer 466 parental control/malware protection settings and flag the 467 consequences of selecting a new provider on these? 469 o If a browser or other edge device can do DoH, what determines if 470 the DoH is the preferred the choice?, e.g. if CPE or set top box 471 devices also supports DNS over TLS, should DoH be an option? If 472 multiple options for DNS resolution are available, what decision 473 process is used to make the customer recommendation and how is 474 this trusted? 476 8. Privacy Concerns 478 Compared to traditional DNS, DoH offers more privacy protection 479 against passive surveillance because requests and replies are carried 480 over an encrypted channel. DoH offers an equivalent amount of 481 privacy protection against passive surveillance as DoT does because 482 both rely on TLS for their security properties. 484 Content Delivery Networks use techniques like EDNS-Client-Subnet 485 (ECS) to return DNS answers that direct a client to an optimal 486 location, for instance the CDN's node in the operator's network which 487 serves the end user. DoH has the potential to be more privacy 488 intrusive than ECS, largely because DoH is based on HTTP and can 489 leverage the rich per-user and per-device tracking that pervades the 490 web today. The implications of that are not yet well understood. 492 A DoH server will have a direct HTTPS connection to the client, 493 assuming there are no middleboxes in the path between them. That 494 could for example enable DoH servers operated by CDNs to carry out 495 much more fine-grained redirection and content delivery, perhaps even 496 on a per-user or per-user-session basis. They would be able to serve 497 content and advertisements based on the end user's choice of 498 operating system, their browser and that browser's configuration in 499 addition to the client's source IP address, web cookie data, or other 500 factors as is prevalent on the web today. 502 Global DoH providers will have access to significantly more DNS query 503 data, and therefore be able to perform richer big data analytics, 504 combining these insights with those obtained from other global 505 platforms (search engines, operating systems, browsers, ad trackers, 506 analytics services, web sites, mobile apps, payment systems, 507 e-commerce stores, social networks, in store Bluetooth beacons, 508 etc.), potentially leading to a poor privacy outcome for consumers. 510 The DoH provider may adhere to different privacy policies than the 511 operator's DNS service, particularly where they are located in 512 different jurisdictions. This may lead to better or worse privacy 513 outcomes for users. 515 Operators in some jurisdictions are required to perform DNS filtering 516 functions on traditional DNS queries and responses. If this 517 functionality has to be provided using DoH, the only available option 518 may be to fully proxy the HTTPS traffic. That represents more of a 519 privacy intrusion than filtering alone. 521 It is feasible that individual applications might have the ability to 522 select their own DoH server, bypassing the system- or operator- 523 defined DoH settings. That could lead to privacy violations because 524 DoH queries get sent to an arbitrary DoH server with unknown privacy 525 policies. 527 9. Security Considerations 529 DoH will give new opportunities for bad actors to propagate malware, 530 spam and botnets. Once they use DoH, as some botnets have already 531 started doing for command-and-control traffic, their DNS traffic will 532 be encrypted and anonymised, making it hard to deploy countermeasures 533 to protect against and mitigate these serious security threats. This 534 is likely to have an adverse impact on cybersecurity both at a 535 network/country level as well as for end users. Use of DoH could 536 make it slower to identify DNS-based DDoS attacks, more difficult to 537 attribute patient-zero for malware infections and harder to block 538 access to botnet command-and-control nodes. A proof of concept 539 exfiltration channel tool based on DoH [GODOH] already exists and it 540 is reasonable to expect others which are much less benign will emerge 541 in the future. 543 DoH queries and responses will be intermingled with other HTTPS port 544 443 traffic. This provides good traffic flow security for the 545 client, because it's not readily clear when a DoH request or reply is 546 taking place (unlike DoT). However network analytics may fail to 547 detect when a malware implant on the client is making DoH requests, 548 which would present a security risk. 550 Security of DoH relies on the TLS session for the HTTPS connection. 551 Therefore it inherits the security guarantees that TLS provides. 552 There may be interactions between DoH and TLS, for example issues 553 arising from DoH servers handling large numbers of TLS connections to 554 DoH clients simultaneously, that have not yet been explored. 556 DNS query traffic is often made available to providers of threat 557 intelligence and reputation services. These providers typically 558 aggregate such data from many operators, process these datasets and 559 then generate whitelists and blocklists which operators can then 560 apply in their networks. DoH is likely to mean there will be less 561 query data readily available for this sort of analysis. Overall DNS 562 query traffic would be spread across a combination of operator-run 563 DNS resolver servers and a number of DoH servers who might (or might 564 not) make their query traffic available to providers of threat 565 intelligence and reputation services. 567 This will have two unwelcome results. First, threat intelligence and 568 reputation services will have fewer data to analyse and therefore 569 have a significantly less complete perspective of end users' DNS 570 behaviour. Second, the quality and effectiveness of the data 571 provided by threat intelligence and reputation services will be 572 materially diminished. This seems likely to reduce the security of 573 networks and users as a result. 575 Although DoH uses TLS to provides authentication and data integrity 576 of the channel between client and resolver, this does not guarantee 577 that the resolver is returning correct DNS data to the client. DoH 578 clients may need to perform DNSSEC validation to verify data received 579 from DoH servers. 581 There is a risk that internal domain names used extensively in 582 managed enterprise networks could leak to external DoH servers, 583 presenting obvious privacy and security issues. 585 DoH can be implemented within the browser, rather than the kernel or 586 an operating system library. It is not yet clear if that will make 587 endpoint-based malware detection more or less effective. 589 Browser APIs will allow web applications to make DoH queries. If 590 individual applications have the ability to select their own DoH 591 server, it is not clear if that change would only apply to DoH 592 lookups by that application or if they had broader scope. When these 593 changes over-ride system- or operator-defined DoH settings, they will 594 affect other processes running on the DoH client and effectively 595 hijack their DNS traffic by rerouting it to the application's DoH 596 provider. 598 The interactions between infrastructure using Network Address 599 Translation (NAT) [RFC3022] and DoH is unclear. In situations where 600 a third party DoH server can return security threat data back to the 601 operator of the originating network, its value is likely to be 602 diminished due to the IP address sharing inherent in using NAT. 604 10. Human Rights Considerations 606 Parental control systems relying on DNS filtering can be bypassed 607 using DoH. This may lead to increased ability of minors to access 608 restricted or otherwise inappropriate content on the Internet. 610 Using DoH to bypass local DNS filtering and provide anonymity for end 611 users is a mixed blessing. Using DoH to bypass country-based DNS 612 filtering may provide end users a way of bypassing censorship 613 mechanisms put in place by restrictive regimes. On the other hand, 614 DoH could also help criminals to evade detection by obscuring the 615 source of their attacks or botnet control nodes, while increasing the 616 commercial tracking of user activity and trade in that data. 618 11. Open Issues for Further Study 620 o DoH's reliance on TLS raises a number of concerns and unknowns. 621 These include scalability in managing session tickets, handling 622 session resumption and the duration of TLS sessions. These will 623 need careful analysis, particularly on DoH servers which get 624 queries from large numbers of DoH clients. 626 o The impact of DNS traffic migrating from UDP and port 53 to TCP 627 and port 443 needs to be modelled because of the extra packets and 628 round-trip times needed for TCP connection setup and the TLS 629 handshake: performance, capacity planning, network engineering and 630 so on. 632 o DoH can leverage the rich per-user and per-device tracking that 633 pervades the web today. Since the implications of that are not 634 yet well understood, further work in this area is needed. 636 o How DoH services will develop new functionality to overcome any 637 inherent performance impact from moving the service out of the 638 operator network. For instance, optimisations to reduce latency 639 in 3/4/5G mobile networks. 641 o Clarification is needed around ECS blocking and options to avoid 642 impacting existing network operator on-net caching strategy. 644 o What DoH service metrics will be available for users to compare 645 DoH providers? 647 12. IANA Considerations 649 This memo includes no request to IANA. 651 13. Acknowledgements 653 Fill this in later 655 14. References 657 14.1. Normative References 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, 661 DOI 10.17487/RFC2119, March 1997, 662 . 664 14.2. Informative References 666 [CSRIC] FCC, "Cybersecurity Risk Management and Best Practices", 667 . 669 [GDPR] European Union, "General Data Protection Regulation (EU) 670 2016/679", 671 . 673 [GODOH] Sensepost, "DNS exfiltration using DoH", 674 . 676 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 677 Address Translator (Traditional NAT)", RFC 3022, 678 DOI 10.17487/RFC3022, January 2001, 679 . 681 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 682 NAT64: Network Address and Protocol Translation from IPv6 683 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 684 April 2011, . 686 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 687 Beijnum, "DNS64: DNS Extensions for Network Address 688 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 689 DOI 10.17487/RFC6147, April 2011, 690 . 692 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 693 and P. Hoffman, "Specification for DNS over Transport 694 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 695 2016, . 697 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 698 Kumari, "Client Subnet in DNS Queries", RFC 7871, 699 DOI 10.17487/RFC7871, May 2016, 700 . 702 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 703 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 704 . 706 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 707 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 708 . 710 [USPS] US Secretary of Commerce, "EU-U.S. Privacy Shield 711 Framework", 712 . 714 Authors' Addresses 716 Andy Fidler 717 BT plc 718 BT Adastral Park 719 Martlesham Heath, Ipswich IP5 3RE 720 UK 722 Email: andrew.fidler@bt.com 724 Bert Hubert 725 OpenXchange 726 Rollnerstrasse 14 727 Nuremberg 90408 728 Germany 730 Email: bert.hubert@open-xchange.com 732 Jason Livingood 733 Comcast 734 1800 Arch Street 735 Philadelphia PA 19118 736 USA 738 Email: jason_livingood@comcast.com 740 Jim Reid 741 RTFM llp 742 St Andrews House 743 382 Hillington Road, Glasgow G51 4BL 744 Scotland 746 Email: jim@rfc1035.com 747 Nic Leymann 748 Deutsche Telekom AG 749 Friedrich-Ebert-Allee 140 750 Bonn 53113 751 Germany 753 Email: N.Leymann@telekom.de