idnits 2.17.1 draft-bertola-bcp-doh-clients-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 date (September 10, 2019) is 1687 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-dprive-bcp-op-03 == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-08 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Bertola 3 Internet-Draft Open-Xchange 4 Intended status: Informational September 10, 2019 5 Expires: March 13, 2020 7 Recommendations for DNS Privacy Client Applications 8 draft-bertola-bcp-doh-clients-01 10 Abstract 12 This document presents operational, policy and security 13 considerations for the authors and publishers of client applications 14 that choose to implement DNS resolution through any of the protocols 15 that provide private, encrypted connections between the application 16 itself and the DNS resolver. As these protocols, depending on 17 implementation choices and deployment models, may impact the Internet 18 significantly at the architectural, legal and policy levels, the 19 document records the current consensus on how these protocols should 20 be used by applications, especially user-facing applications meant 21 for mass usage by non-technical consumers. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 13, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Notation and Conventions . . . . . . . . . . . . 3 59 3. Architectures for Name Resolution Services . . . . . . . . . 3 60 4. Issues and Recommendations . . . . . . . . . . . . . . . . . 5 61 4.1. Trust Model and User Choice . . . . . . . . . . . . . . . 5 62 4.2. Consolidation . . . . . . . . . . . . . . . . . . . . . . 7 63 4.3. Competition and Network Neutrality . . . . . . . . . . . 9 64 4.4. Namespace Fragmentation . . . . . . . . . . . . . . . . . 10 65 4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.6. Content Access Control . . . . . . . . . . . . . . . . . 12 67 4.7. Security and Network Management . . . . . . . . . . . . . 13 68 4.8. Jurisdiction . . . . . . . . . . . . . . . . . . . . . . 15 69 4.9. Disaster Recovery . . . . . . . . . . . . . . . . . . . . 17 70 4.10. User Support . . . . . . . . . . . . . . . . . . . . . . 17 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 72 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 73 7. Human Rights Considerations . . . . . . . . . . . . . . . . . 18 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 78 10.2. Informative References . . . . . . . . . . . . . . . . . 19 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 81 1. Introduction 83 As a reaction to growing concerns about widespread "pervasive 84 monitoring" activities, the IETF declared these practices to be an 85 attack [RFC7258] and started work to promote the encryption of the 86 transport of information across the Internet. 88 The Domain Name System [RFC1034] is a fundamental element of the 89 Internet, as almost any online activity starts with one or more DNS 90 queries, which can be used to track the services and the content that 91 the user is accessing, and even to redirect or disallow such access; 92 DNS traffic deriving from the activity of human beings constitutes 93 sensitive and valuable personal information. Section 2.4.1 of 94 [I-D.bortzmeyer-dprive-rfc7626-bis] describes the risks created by 95 the unencrypted transmission of such information. 97 To mitigate these risks, two new standards have been developed to 98 encrypt the transport of DNS queries and replies between the user's 99 machine and the recursive resolver: DNS-over-TLS [RFC7858] and DNS- 100 over-HTTPS [RFC8484]. The adoption of these protocols is still 101 limited, but early deployments, especially of the latter, have raised 102 a number of issues that pertain to consolidation and centralization, 103 other privacy risks, various cases of content control, network 104 security and management, applicable jurisdiction and more. 106 These issues, if not addressed, could outweigh the benefits deriving 107 from the encryption of DNS transport. Some of them can be addressed 108 at the server side of the connection; they are the subject of 109 [I-D.ietf-dprive-bcp-op]. However, some of these issues derive from 110 the behaviour of client applications that implement the protocols and 111 use them to query the DNS as necessary for their activities. 113 This document presents the best practices that address these issues 114 at the client side of the connection and that, as far as possible, 115 could allow an uncontroversial and positive deployment of encrypted 116 DNS transport protocols. 118 2. Requirements Notation and Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 Throughout this document, values are quoted to indicate that they are 125 to be taken literally. When using these values in protocol messages, 126 the quotes MUST NOT be used as part of the value. 128 3. Architectures for Name Resolution Services 130 It is possible for a device to perform full DNS name resolution on 131 its own, without relying on any recursive DNS resolver - indeed, this 132 was often the case in the early usage of the DNS. 134 However, since when the Internet became a mass affair, the DNS name 135 resolution service in consumer Internet access services has been 136 generally provided by a recursive DNS resolver on the local network 137 ("local resolver"), supplied by the same ISP that is providing the 138 user with Internet access, often through automated configuration 139 mechanisms such as DHCP [RFC2131]. 141 More recently, public DNS resolvers ("remote resolvers"), provided on 142 an Internet scale by a few big operators, have been gaining ground; 143 users have been able to set them as the resolver for all their 144 applications at once, by changing a configuration item in their 145 devices. 147 Thus, the current architecture for mainstream DNS resolution services 148 relies on the following assumptions: 150 1. All the applications on the same device use the same resolver, 151 through a library provided by the operating system; 153 2. By default, the device will automatically discover and use the 154 resolver provided by the local network; 156 3. The user is in charge of deciding which resolver will be used, 157 either by silently accepting the default, or by setting a 158 specific resolver in the device configuration. 160 Early deployments of DNS-over-TLS have generally followed the same 161 model; in the first mobile operating system that has implemented 162 support for the protocol, the system will try to discover whether the 163 resolver configured in the operating system supports DNS-over-TLS 164 connections, and if so, it will automatically upgrade the connection 165 to the new protocol while continuing to use the same resolver; 166 otherwise, it will keep using the unencrypted connection. 168 Early deployments of DNS-over-HTTPS have followed a different model. 169 The first major Web browser releasing support for DNS-over-HTTPS has 170 announced the intention to follow a service architecture based on 171 different assumptions: 173 1. Each application will use its own resolver, bypassing the library 174 provided by the operating system; 176 2. No automatic discovery of resolvers on the local network is 177 performed; 179 3. The application is in charge of determining which resolver will 180 be used, which could be different than the one configured in the 181 operating system, and can direct this choice by selecting and 182 providing one as the default for all users globally, or even by 183 limiting the user's choice to a list of resolvers vetted by the 184 application maker. 186 In the rest of the document, we will refer to this new architecture 187 as "application-level name resolution", and to the traditional one as 188 "network-level name resolution". More specifically, we will refer to 189 point 3 of the above list as "application-level resolver selection". 191 While the document will also address the issues that derive simply 192 from the switch to an encrypted connection, most of the issues that 193 have been noticed during the early deployment efforts for DNS-over- 194 HTTPS do not derive from the protocol in itself, but rather from the 195 switch to application-level name resolution under the assumptions 196 above, and most frequently from the adoption of application-level 197 resolver selection. 199 Other possible architectures have also been identified: for example, 200 applications could use different resolvers for each of the different 201 servers that they have to connect to, or the servers could push DNS 202 records to the client even before they are actually queried. As 203 these models are still speculative, the issues that they would 204 generate are not currently addressed by this document. 206 4. Issues and Recommendations 208 This section classifies the issues that are created by the deployment 209 of encrypted DNS protocols and/or by the change of resolution 210 architectures on the client side, and presents recommendations to 211 address them. 213 4.1. Trust Model and User Choice 215 With network-level name resolution, users are in charge of the choice 216 of the resolver used by all their applications. Advanced and 217 educated users make full use of that opportunity, and choose to send 218 their DNS queries to an operator they trust, either by configuring a 219 specific resolver in the operating system or on the router that 220 manages their home network, or as part of a broader traffic 221 encryption and redirection service (e.g. VPNs). Other users will 222 just rely on the local network's server; for home users, this will be 223 provided by their Internet access provider, which they also picked, 224 thus giving them at least some degree of trust. A different, less 225 trusted relationship exists when users that did not configure a 226 specific server connect to a local network which is not their own, 227 for example in Internet cafes or hotels; in that case, they may be 228 led to use a resolver which they do not trust. 230 Also, in the absence of encryption, the local network operator could 231 still be able to track or even alter the DNS queries and replies that 232 the user has directed to a non-local resolver. Unless this has been 233 agreed with the user or is mandated by applicable legislation, this 234 would be a breach of the user's trust and is a good reason to promote 235 the adoption of encrypted DNS protocols. 237 With application-level name resolution, and especially with 238 application-level resolver selection, users lose at least part of 239 their control. Some applications may actually not give the user any 240 choice, and just use their own resolver all the times; some others 241 may provide configuration options, but still direct the queries to 242 their own resolver as a default, requiring specific action for users 243 to keep their DNS traffic going to the resolver that they already 244 configured in the operating system. 246 Such a change of default behaviour would break the expectations of 247 many users; unless appropriate communication is given and consent is 248 acquired, both the users that explicitly configured a resolver in the 249 operating system, and the users that want their device to use the 250 local network's resolver, will be surprised by the application 251 sending DNS queries to another server instead. On the other hand, 252 for less technical users that trust the application maker to make a 253 better choice of resolvers on their behalf, the new behaviour could 254 be in line with their expectations. 256 However, also given the high sensitivity of the personal information 257 embedded in DNS queries, it is important to ensure that it is 258 ultimately the user, rather than any third party, that determines 259 where their DNS queries should go, and explicitly consents to any 260 choice of resolver that cannot be expected, or to delegating the 261 choice to another party. 263 This leads to the following recommendations: 265 1. Users MUST have the final word on which resolver is used by each 266 application. 268 2. Applications MUST NOT use a different resolver operator than the 269 one that would be used by the operating system, unless the user 270 has actively told the application to use a different resolver 271 operator and has given explicit and informed consent to the 272 change. 274 3. Applications MUST provide users with a configuration mechanism 275 that allows them to tell the application to use any resolver the 276 user wants. 278 4. Applications SHOULD provide users with adequate information on 279 the location, ownership, data management policies and operational 280 practices of each resolver, at least for the resolvers that they 281 provide as hard-coded configuration options. 283 5. Applications SHOULD support, if available, easy ways for the user 284 to direct all applications on the device to use a specific 285 resolver and a specific protocol, without the need to configure 286 them one by one. 288 For recommendation #2, it may happen that the resolver configured in 289 the operating system does not support encrypted DNS protocols. In 290 this case, the application SHOULD first of all try to determine 291 whether the operator of the non-encrypted resolver that would be used 292 by the operating system also provides any encrypted DNS resolver, 293 through standardized discovery mechanisms such as 294 [I-D.ietf-doh-resolver-associated-doh]; in that case, it SHOULD use 295 that operator's encrypted resolver instead of the unencrypted one. 297 For recommendation #4, the guidelines in [I-D.ietf-dprive-bcp-op] 298 SHOULD be followed; applications could explore ways to make them more 299 understandable to average Internet users, for example through the use 300 of standardized visual aids. At the same time, due to the complexity 301 and changing nature of this information, applications could simply 302 provide links to where the operator makes it available; a 303 standardized and automated way for resolvers to make this information 304 available to applications would be desirable. 306 For recommendation #5, in most operating systems and devices it is 307 yet to be discussed how to achieve the objective of letting the user 308 set the preferred resolver and protocol in all the applications at 309 once; the principle, however, deserves to be stated as a recommended 310 direction for future development. 312 4.2. Consolidation 314 Currently, with network-level name resolution, DNS resolution 315 activities are globally spread across a huge number of resolvers, 316 possibly in the range of the hundreds of thousands or even millions; 317 while some consolidation is happening, mostly into some big remote 318 resolver platforms, still it takes the thousand biggest resolvers to 319 aggreagate 90% of global DNS traffic. Users that keep the default of 320 using the local network's resolver see their personal DNS queries 321 spread across multiple servers as they move; users that configure a 322 specific public resolver have their queries concentrated on a single 323 resolver system, but they can pick one that they trust. 325 However, in many cases, the global market for user applications is 326 much more consolidated than the global market for Internet access and 327 for DNS resolution services. More specifically, estimates for the 328 global browser market currently show one maker having around 60% of 329 the market, and the first four together having over 90% of it. While 330 these market shares may change in the future, the presence of one or 331 a few dominant browsers has almost always been the case since the 332 advent of mass usage of the World Wide Web. 334 As application-level name resolution turns the application maker into 335 a potential gatekeeper in the choice of the resolver, there is a 336 concern that each application maker could lead its users to the 337 adoption of one specific resolver operator, or limit their choice to 338 a few options that the maker has picked for its own reasons. 340 While it is understandable that an application maker may want to help 341 its users make a good choice of resolver by using its technical 342 expertise to evaluate and select a narrow set of recommended 343 resolvers, this practice would open opportunities for misuse, as 344 applications could recommend resolvers not because of a fair 345 evaluation, but because of an existing business partnership in the 346 mutual economic interest, or even because the resolver is run 347 directly by the application maker. 349 In the end, this could lead to a dramatic consolidation of global 350 name resolution operators, with a few server systems managing the 351 broad majority of global resolutions. This, in turn, would have 352 several negative consequences, which will be discussed in the 353 following sections of the document. 355 However, consolidation is an architectural problem in itself; the 356 Internet was designed to be as decentralized as possible, to increase 357 its resilience and ultimately the freedom of its users. The concern 358 over the centralizing effect of encrypted DNS protocols has been 359 recorded for example in [I-D.arkko-iab-internet-consolidation], 360 section 2.5, and has to be addressed by preventing the use of a 361 strong position in the market for a specific type of client 362 application, especially a ubiquitous one such as browsers, to 363 centralize DNS resolutions and establish a strong position in DNS 364 name resolution services. 366 This would already be addressed by the recommendations in section 367 4.1, but it also leads to the following additional recommendations: 369 1. Applications MUST NOT prioritize any specific resolver over 370 others unless told so by the user, or design their user 371 interaction to lead users towards choosing a specific resolver or 372 one of a few specific resolvers. 374 2. If possible, and if desired by the user, applications SHOULD 375 provide ways to spread their DNS resolution traffic across the 376 highest possible number of recursive resolvers. [NOTE: this 377 recommendation is actually a placeholder, as there are drawbacks 378 to this idea and other, better methods could be devised - this is 379 TBD] 381 3. If applications would like to ensure that their users can pick a 382 resolver that has been vetted under a set of criteria, the 383 definition, verification and enforcement of these criteria SHOULD 384 be deferred to an independent multi-stakeholder organization, 385 making these criteria public and objective and giving any 386 resolver operator from any part of the Internet a fair chance to 387 be admitted to the list of vetted services; in any case, users 388 MUST still be free to adopt servers outside of the vetted list if 389 they so desire. 391 4.3. Competition and Network Neutrality 393 The possible inception of a stricter relationship between application 394 makers and resolver operators also creates issues related to 395 competition, which can in turn have effects on the architecture and 396 performance of the network and on its capacity for permissionless 397 innovation, and compromise the neutrality of network transport, as 398 DNS resolution is a fundamental step in establishing any network 399 connection. 401 In addition to the consolidation effect described in the previous 402 section, any relationship between the application maker and a 403 resolver operator that could lead the application to direct users to 404 a specific resolver could be used to reduce the opportunities 405 available to other resolver operators, including innovative ones, and 406 even to other application makers, for example by virtue of exclusive 407 service agreements. This can be a likely case when the application 408 maker and the resolver operator are the same entity, but it could 409 happen also when the application maker and the resolver operator are 410 two different entities that have established a business partnership 411 in the mutual interest. 413 Another case of anti-competitive effect could happen when the 414 resolver operator also operates another service that depends for its 415 effectiveness on the results of the DNS resolution process - for 416 example, content delivery networks. Resolver operators that also 417 operate CDNs could provide slower or less effective DNS resolution 418 for access to content distributed by their competitors. 420 While this matter will also be under the purview of national and 421 international market regulations, there are some recommendations - in 422 addition to those in the previous section, that also address this 423 issue - that can be made in terms of best practices, to neutralize as 424 far as possible any direct relationship between the application maker 425 and the resolver operator: 427 [ to be discussed ] 429 4.4. Namespace Fragmentation 431 If each application could pick a different resolver, there is a 432 chance that different applications would receive different replies to 433 the same DNS queries, leading to confusing user experiences, 434 potential attack surfaces and network management and debugging 435 problems, and in the end to the fragmentation of the Internet into 436 non fully interoperable chunks. 438 The only way to prevent any occurrence of this case would be to 439 require all applications on the same device to use the same resolver, 440 as in the current network-level resolution model; however, such 441 requirement would be considered too restrictive. Recommendations #2 442 and #3 in section 4.1 are however meant to make this case a special 443 exception, rather than the norm, and thus mitigate this problem. 445 However, when allowing different applications to use different 446 resolvers, there is a situation that would significantly endanger the 447 stability of the Internet. Currently, as the application and the 448 resolver are generally provided by two independent entities, and as 449 the application cannot know in advance which resolver will be used, 450 applications cannot rely on predetermined non-standard behaviour by a 451 specific resolver. With application-level resolver selection, 452 applications that enjoy a significant market share could direct users 453 to resolvers that employ alternate DNS namespaces that they control, 454 or start to create and remove top level domains outside of the 455 collectively agreed policy frameworks. 457 The global uniqueness of the DNS namespace and its collective policy- 458 making procedures should be preserved, and this leads to the 459 following additional recommendation: 461 1. Applications SHOULD NOT adopt alternate DNS namespaces or promote 462 the use of resolvers that do not rely on the global DNS root 463 server system. 465 2. Applications SHOULD NOT deviate from the DNS namespace management 466 policies, technical standards and operational practices that are 467 defined in the relevant Internet governance venues. 469 Regarding recommendation #1, there may be specific use cases in which 470 a user may want to use an alternate namespace and root server set, 471 and applications, if they want, should be free to support them; 472 however, these cases must be exceptions and not for mainstream usage. 474 4.5. Privacy 476 Protecting the user's privacy is the primary aim of transitioning the 477 DNS to encrypted communications. However, risks to privacy deriving 478 from DNS communications are not limited to the eavesdropping of 479 unencrypted DNS communications; [I-D.bortzmeyer-dprive-rfc7626-bis] 480 lists, in section 2.4.2, several privacy risks that still exist even 481 when DNS communications are encrypted; and, in section 2.5.1, it 482 describes the risks that derive from the behaviour of the resolver in 483 use, independently from whether the connection is encrypted or not. 485 To address the former category of privacy risks, some have suggested 486 that, through the use of DNS-over-HTTPS, the user's requests could be 487 hidden within unrelated HTTPS traffic, locating DNS-over-HTTPS 488 servers at the same IP address and port of widely used web servers. 489 However, this method creates security and legal issues that are 490 documented in the following sections of this document, and so it is 491 not recommended unless the privacy gain must prevail upon any other 492 consideration, for example because of the extreme sensitivity of the 493 online activity or because of a hostile environment that could lead 494 to significant personal risks. 496 In all other cases, users that feel the need for further obfuscation 497 of their encrypted DNS communication should rather be directed to 498 spreading their communications across a great number of encrypted 499 resolvers, as per recommendation #2 of section 4.2, making it harder 500 to track the entirety of their DNS exchanges. Moreover, if privacy 501 is so important, users should consider that they also need to encrypt 502 the rest of the communications, and not just the resolution of domain 503 names; thus, using a VPN for all their traffic might just be easier 504 and better. 506 To address the latter category of privacy risks, the first and 507 foremost mitigation measure is to allow each user to pick a resolver 508 that is managed by an organization that they trust, under appropriate 509 regulatory conditions, privacy policies and operational practices. 510 While "privacy-friendly" applications might (and, indeed, should) 511 help users in making this choice, there is not a unique, globally 512 applicable agreement on what constitutes a "privacy-friendly" 513 resolver, and it is hard to ensure that all application makers will 514 always make disinterested choices in the pure interest of the user; 515 so it must be the user, in the end, to decide who to entrust with 516 their personal information. The recommendations in sections 4.1 and 517 4.2 thus also contribute to mitigate this type of risks. 519 In addition, specific technical recommendations can be made to 520 prevent applications from adopting practices that would make it 521 easier for the resolver operator to track and fingerprint the user, 522 mirroring the ones that have been developed in 523 [I-D.ietf-dprive-bcp-op] section 5: 525 1. Applications MUST authenticate the resolver they connect to, if 526 they have securely discovered the information required to do so. 528 2. In the case of DNS-over-HTTPS, applications SHOULD NOT attach or 529 receive HTTP cookies on the connections used for the DNS message 530 exchange, unless there is a specific use case for cookies that 531 has been explicitly requested by the user. 533 3. [to be continued] 535 For recommendation #1, and for DNS-over-TLS, a discussion of resolver 536 authentication methods and possibilities can be found in [RFC8310]. 538 For recommendation #2, additional considerations on privacy when 539 using HTTPS as a transport mechanism for other protocols can be found 540 in section 6.1 of [I-D.ietf-httpbis-bcp56bis]. 542 4.6. Content Access Control 544 DNS name resolution services are commonly chosen as a platform to 545 control user access to content; while there are other mechanisms in 546 use, checking and blocking destinations at the DNS level is an 547 effective and relatively inexpensive one. As a consequence, the 548 choice of the resolver also determines whether the user will be able 549 to access certain destinations on not, depending on the policies 550 applied by the individual resolver. 552 Sometimes, on unencrypted DNS connections, content control policies 553 will also be applied to DNS connections directed to other resolvers 554 having a different policy than the local network's one, though this 555 is made impossible by the switch to encrypted DNS connections. 557 The motivations, the procedures, and the types of content subject to 558 blocking are very variable. Some of the filtering activities are 559 meant to increase the security and health of the network; they can be 560 aimed at non-human clients, such as bots, trying to prevent them from 561 connecting to their command and control servers; or they can try to 562 prevent unaware users from connecting to phishing and malware 563 websites. 565 Other filtering activities are meant to make some content 566 inaccessible because it violates the law in the user's and/or the 567 resolver's jurisdiction, or because of court rulings that mandate the 568 block. In authoritarian countries, content may be blocked to prevent 569 criticism of the ruling entity, while in democratic countries it can 570 be blocked to defend the safety and rights of some parties and 571 prevent violence and attacks on democracy. Destinations may also be 572 made inaccessible, independently from their content, for lack of 573 compliance with any applicable regulation, such as requirements for 574 licenses or the payment of taxes in the user's country. 576 The opinions on the appropriateness of these practices are highly 577 influenced by local culture, history and socio-political 578 environments, as well as by each individual's set of values, and it 579 is thus impossible to make blanket recommendations on whether and 580 when they should be forbidden, allowed, or actively supported; the 581 only possible recommendation is to follow the applicable regulations. 583 In some cases, however, users actually demand DNS-based content 584 control services to shape their own Internet access: for example, 585 families that want to make sure that their children using the 586 Internet from home cannot access inappropriate websites; businesses 587 that want to restrict the way their employees can use the Internet in 588 the office during working hours. 590 This leads to the following recommendations: 592 1. Applications MUST NOT prevent users from using any DNS-based 593 content control service that they freely choose to adopt. 595 2. Applications SHOULD comply with any legislation and legal ruling 596 on content control that applies to them in the jurisdiction where 597 they are being used. 599 Further considerations on the relationship between applications and 600 applicable legislation will be made in section 4.7. 602 4.7. Security and Network Management 604 Network management and network security practices often rely on 605 checks and policies implemented at the DNS level, through the 606 monitoring and mangling of the DNS queries that the users of the 607 local network send to the local resolver. For example, these 608 practices include checking for any unusual patterns in DNS traffic to 609 detect devices that have been infected with malware; blocking queries 610 for known botnet command-and-control servers to make it impossible 611 for bots to communicate with them and take orders; implementing a 612 content control list of web destinations that the network 613 administrator considers dangerous; associating certain names to 614 different IP addresses, some of which may be private, depending on 615 the client and on its topological location; creating names in special 616 use or non-standard top level domains and making them resolvable only 617 from the inside of the local network. 619 Especially the use of local names and "split horizon" configurations 620 is a widely used security practice in corporate network environments; 621 using a resolver located outside of the network would break this 622 mechanism and at the same time leak information that would be very 623 valuable to an attacker. 625 These practices rely on forcing all the users of the local network to 626 use the local resolver, rather than a remote public resolver; this 627 requirement is generally enforced through one or more of the 628 following practices: 630 a. Making sure that all devices that are connected to the local 631 network are configured to use the local resolver, disallowing the 632 users from modifying this configuration entry; 634 b. Blocking access to remote resolvers at the edge of the local 635 network, for example through firewalls and blocks by destination 636 IP address and/or port; 638 c. Examining, and if necessary amending, all DNS queries and replies 639 in transit towards remote resolvers. 641 The switch to encrypted DNS connections makes practice c) generally 642 impossible; the switch to application-level resolver selection also 643 makes a) impossible, unless the network administrator can prevent the 644 installation of any application on all the devices connected to the 645 network, which is not easily feasible in most cases. Finally, the 646 implementation of "mixed mode" DNS-over-HTTPS, obfuscating the 647 traffic within ordinary HTTPS connections to widely used web hosts, 648 would make also practice b) impossible. 650 So, the deployment of encrypted DNS over dedicated connections 651 disables c), but still leaves a) and b) as options to network 652 administrators; however, the deployment of DNS-over-HTTPS in mixed 653 mode disables all three practices and leaves the network 654 administrators powerless; additionally, it even provides an 655 undetectable data exfiltration vector for malicious applications that 656 are trying to steal confidential information from the local network 657 and forward it to the outside. 659 While disabling control by the local network administrator might 660 actually be a positive intent in very specific cases, disabling all 661 these security practices at once is dangerous and inappropriate in 662 most cases. It is especially problematic on private networks that 663 host sensitive or commercially valuable information, as they need to 664 be able to provide some degree of connectivity to the Internet while 665 scrutinizing and limiting its usage to guarantee security. 667 Noting that even [RFC7258], in section 2, stresses that "Making 668 networks unmanageable to mitigate pervasive monitoring is not an 669 acceptable outcome", and calls for "an appropriate balance" between 670 encryption and network management needs, the following 671 recommendations, in addition to those in section 4.1., represent such 672 balance: 674 1. Applications SHOULD NOT adopt the practice of hiding their 675 encrypted DNS traffic in ways that prevent the local network 676 administrator from isolating it, monitoring it (without breaking 677 the encryption) and, if desired, blocking it; exceptions to this 678 principle MUST be motivated by a clear and compelling use case 679 which cannot be addressed otherwise, and their use MUST be 680 limited to such use case. [Note: of course I am sure that many 681 people will want to discuss this - the idea is to not stop this 682 from happening when it is really useful, but also restrict its 683 usage to when it is really useful, leaving network admins with 684 the possibility to block external encrypted resolvers if they 685 want, without starting a technical "arms race".] 687 2. [to be continued] 689 Further reasons supporting recommendation #1 can be found in sections 690 4.5 and 4.8. 692 4.8. Jurisdiction 694 The current prevailing practice of using local resolvers, located 695 topologically near to the user, generally ensures that the resolver 696 and the user fall under the same jurisdiction. This allows the 697 country managing such jurisdiction to apply rules and policies to the 698 user's Internet access by acting upon the resolver, recommending or 699 mandating actions to the ISP that runs the resolver. 701 The use of remote resolvers, in most cases located in a different 702 country and under a different jurisdiction than the user, has already 703 provided a way for users to bypass their local laws. Many countries 704 have tolerated this loss of sovereignty because it only affected a 705 minority of users, possibly smarter technical users that could have 706 anyway found other ways to bypass national rules applied at the 707 resolver level, such as running their own recursive resolver. Other 708 countries have instead engaged in enforcing their Internet access 709 rules at other levels, such as by requiring firewalls at each 710 connection between any national network and the broader Internet and 711 filtering out destinations by IP address, or requiring the ISPs to 712 apply similar blocks on each user's Internet connectivity. 714 In [RFC7754], the IETF has recommended the use of filtering at the 715 endpoints, rather than inside the network, to address issues that 716 require access control to Internet destinations; but filtering at the 717 edges is much harder to set up and to enforce for countries, and the 718 same RFC agrees that "a hybrid approach that combines endpoint-based 719 filtering with network filtering may prove least damaging". In this 720 regard, making resolver-level law-mandated filtering policies 721 impossible is anyway likely to push more countries to mandate 722 heavier, more damaging filtering practices at the IP address level. 724 From the user's viewpoint, a change in jurisdiction may be beneficial 725 or damaging, depending on which issues are most important for the 726 user and on the applicable legislation in the user's and, if 727 different, in the resolver's country. Users located in jurisdictions 728 that restrict their rights may actively seek to use a resolver in a 729 different jurisdiction to bypass the restrictions. Users that enjoy 730 a high degree of rights in their country, such as extended 731 protections for privacy and network neutrality, may reject the use of 732 a resolver in another jurisdiction not to lose such protections. 734 It is out of scope for the IETF to decide whether the policies and 735 laws of any country should be supported or opposed. By leaving as 736 much control as possible to the user, as recommended in section 4.1, 737 each user is allowed to decide whether to seek the use of a resolver 738 in a different jurisdiction or stay within their own, bearing the 739 responsibility for any legal consequence that might derive from that 740 decision; and it is important that such a decision is not taken 741 lightly and especially is not taken by the application without 742 telling the user, as the user could otherwise unwillingly end up in 743 legal troubles. 745 At the same time, while individual users and individual application 746 makers may have different views and follow other practices, it is 747 inappropriate for the IETF as a whole to promote the deployment of 748 technologies in a way that is explicitly designed to undermine any 749 country's sovereignty and jurisdiction. This is another reason to 750 support recommendation #1 in section 4.7 and recommendation #2 in 751 section 4.6. More generally, the following recommendations can be 752 devised: 754 1. Applications SHOULD clearly inform the user whenever the resolver 755 that it is going to be employed lies under a jurisdiction 756 different than the one of the user. 758 2. Applications SHOULD NOT adopt a resolver located under a 759 jurisdiction different than the user's one, unless the user has 760 explicitly consented to such change of jurisdiction, and unless 761 the user's jurisdiction allows the use of resolvers located in a 762 different country. 764 4.9. Disaster Recovery 766 Remote resolvers rely on global Internet connectivity to be able to 767 serve users from every part of the world. However, there may be 768 cases in which long distance Internet connectivity is so poor to make 769 the use of remote resolvers ineffective, or has been greatly reduced 770 or even completely severed by the effects of natural disasters, 771 upstream legal and contractual issues or any other special situation. 773 In these cases, it is important that applications can continue 774 working if connectivity to a local resolver can be established, as 775 the resolver, even with global connectivity issues, can still provide 776 access to much needed local resources. 778 This leads to the following recommendation: 780 1. Applications, when using a remote resolver, SHOULD monitor the 781 availability of sufficient connectivity to it, and SHOULD prompt 782 the user to switch temporarily to a local resolver, if available, 783 when such connectivity is not available. 785 4.10. User Support 787 Functioning DNS resolution is a requirement to make Internet 788 connectivity work, and, when it does not, most users have a hard time 789 discerning the specific technical factor that prevents it from 790 working. As they generally acquire their Internet connectivity from 791 a local ISP, they will thus contact the ISP's support desk whenever 792 the connectivity does not work, regardless of the actual cause. 793 However, if the application is using a remote resolver, the ISP's 794 support desk will not be able to know whether such resolver is 795 experiencing operational issues or applying policies that make the 796 user's desired action fail. 798 It is thus important that application makers, remote resolver 799 operators and ISPs cooperate to allow users to get support on their 800 Internet access problems. For what regards applications, this leads 801 to the following recommendations: 803 1. Applications SHOULD make it easy for users to determine whether 804 any failure that they experience in the use of the application 805 can be attributed to a failure in DNS resolution. 807 2. Applications SHOULD cooperate with remote resolver operators to 808 direct users that experience problems due to resolver failures to 809 the support service of the resolver operator. 811 3. Applications SHOULD provide easy ways for their users to retrieve 812 the information on the resolver currently in use, so that they 813 can pass on this information to whoever is helping them to 814 restore their connectivity. 816 5. Security Considerations 818 The use of encrypted DNS protocols is beneficial to security as it 819 prevents unauthorized third parties from altering the DNS queries and 820 replies, but it also creates new security risks by disrupting a 821 number of existing and commonly used practices for network security, 822 and by providing, under certain conditions, a mechanism for data 823 exfiltration from within a network through the submission of 824 appropriately designed DNS queries. 826 More detailed security considerations can be found in section 4.7 of 827 this document. 829 6. Privacy Considerations 831 The use of encrypted DNS protocols in itself is beneficial to privacy 832 as it prevents eavesdropping of the connection. However, the issues 833 created by the deployment model can lead to an overall loss of 834 privacy, for example because the user is led to adopt a resolver 835 operator that offers less privacy protection than the one they are 836 currently using, or that is located under a jurisdiction that offers 837 less privacy protection. 839 Issues specifically related to privacy, and recommendations to 840 address them, are discussed in section 4.5 of this document. 842 7. Human Rights Considerations 844 [ to be written ] 846 8. IANA Considerations 848 This document has no actions for IANA. 850 9. Acknowledgements 852 [ to be written ] 854 10. References 856 10.1. Normative References 858 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 859 Requirement Levels", BCP 14, RFC 2119, 860 DOI 10.17487/RFC2119, March 1997, 861 . 863 10.2. Informative References 865 [I-D.arkko-iab-internet-consolidation] 866 Arkko, J., Trammell, B., Nottingham, M., Huitema, C., 867 Thomson, M., Tantsura, J., and N. Oever, "Considerations 868 on Internet Consolidation and the Internet Architecture", 869 draft-arkko-iab-internet-consolidation-02 (work in 870 progress), July 2019. 872 [I-D.bortzmeyer-dprive-rfc7626-bis] 873 Bortzmeyer, S. and S. Dickinson, "DNS Privacy 874 Considerations", draft-bortzmeyer-dprive-rfc7626-bis-02 875 (work in progress), January 2019. 877 [I-D.ietf-doh-resolver-associated-doh] 878 Hoffman, P., "Associating a DoH Server with a Resolver", 879 draft-ietf-doh-resolver-associated-doh-03 (work in 880 progress), March 2019. 882 [I-D.ietf-dprive-bcp-op] 883 Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A. 884 Mankin, "Recommendations for DNS Privacy Service 885 Operators", draft-ietf-dprive-bcp-op-03 (work in 886 progress), July 2019. 888 [I-D.ietf-httpbis-bcp56bis] 889 Nottingham, M., "Building Protocols with HTTP", draft- 890 ietf-httpbis-bcp56bis-08 (work in progress), November 891 2018. 893 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 894 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 895 . 897 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 898 RFC 2131, DOI 10.17487/RFC2131, March 1997, 899 . 901 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 902 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 903 2014, . 905 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 906 Nordmark, "Technical Considerations for Internet Service 907 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 908 March 2016, . 910 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 911 and P. Hoffman, "Specification for DNS over Transport 912 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 913 2016, . 915 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 916 for DNS over TLS and DNS over DTLS", RFC 8310, 917 DOI 10.17487/RFC8310, March 2018, 918 . 920 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 921 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 922 . 924 Author's Address 926 Vittorio Bertola 927 Open-Xchange 928 Via Treviso 12 929 Torino 10144 930 Italy 932 Email: vittorio.bertola@open-xchange.com 933 URI: https://www.open-xchange.com