| Network Working Group | V. Bertola |
| Internet-Draft | Open-Xchange |
| Intended status: Informational | March 10, 2019 |
| Expires: September 11, 2019 |
Recommendations for DNS Privacy Client Applications
draft-bertola-bcp-doh-clients-00
This document presents operational, policy and security considerations for the authors and publishers of client applications that choose to implement DNS resolution through any of the protocols that provide private, encrypted connections between the application itself and the DNS resolver. As these protocols, depending on implementation choices and deployment models, may impact the Internet significantly at the architectural, legal and policy levels, the document records the current consensus on how these protocols should be used by applications, especially user-facing applications meant for mass usage by non-technical consumers.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2019.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
As a reaction to growing concerns about widespread "pervasive monitoring" activities, the IETF declared these practices to be an attack [RFC7258] and started work to promote the encryption of the transport of information across the Internet.
The Domain Name System [RFC1034] is a fundamental element of the Internet, as almost any online activity starts with one or more DNS queries, which can be used to track the services and the content that the user is accessing, and even to redirect or disallow such access; DNS traffic deriving from the activity of human beings constitutes sensitive and valuable personal information. Section 2.4.1 of [I-D.bortzmeyer-dprive-rfc7626-bis] describes the risks created by the unencrypted transmission of such information.
To mitigate these risks, two new standards have been developed to encrypt the transport of DNS queries and replies between the user's machine and the recursive resolver: DNS-over-TLS [RFC7858] and DNS-over-HTTPS [RFC8484]. The adoption of these protocols is still limited, but early deployments, especially of the latter, have raised a number of issues that pertain to consolidation and centralization, other privacy risks, various cases of content control, network security and management, applicable jurisdiction and more.
These issues, if not addressed, could outweigh the benefits deriving from the encryption of DNS transport. Some of them can be addressed at the server side of the connection; they are the subject of [I-D.ietf-dprive-bcp-op]. However, some of these issues derive from the behaviour of client applications that implement the protocols and use them to query the DNS as necessary for their activities.
This document presents the best practices that address these issues at the client side of the connection and that, as far as possible, could allow an uncontroversial and positive deployment of encrypted DNS transport protocols.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.
Traditionally, the DNS name resolution service for ordinary Internet users has been generally provided by a recursive DNS resolver on the local network ("local resolver"), supplied by the same ISP that is providing the user with Internet access, often through automated configuration mechanisms such as DHCP [RFC2131].
More recently, public DNS resolvers ("remote resolvers"), provided on an Internet scale by a few big operators, have been gaining ground; users have been able to set them as the resolver for all their applications at once, by changing a configuration item in their devices.
Thus, the current architecture for mainstream DNS resolution services relies on the following assumptions:
Early deployments of DNS-over-TLS have generally followed the same model; in the first mobile operating system that has implemented support for the protocol, the system will try to discover whether the resolver configured in the operating system supports DNS-over-TLS connections, and if so, it will automatically upgrade the connection to the new protocol while continuing to use the same resolver; otherwise, it will keep using the unencrypted connection.
Early deployments of DNS-over-HTTPS have followed a different model. The first major Web browser releasing support for DNS-over-HTTPS has announced the intention to follow a service architecture based on different assumptions:
In the rest of the document, we will refer to this new architecture as "application-level name resolution", and to the traditional one as "network-level name resolution". More specifically, we will refer to point 3 of the above list as "application-level resolver selection".
While the document will also address the issues that derive simply from the switch to an encrypted connection, most of the issues that have been noticed during the early deployment efforts for DNS-over-HTTPS do not derive from the protocol in itself, but rather from the switch to application-level name resolution under the assumptions above, and most frequently from the adoption of application-level resolver selection.
Other possible architectures have also been identified: for example, applications could use different resolvers for each of the different servers that they have to connect to, or the servers could push DNS records to the client even before they are actually queried. As these models are still speculative, the issues that they would generate are not currently addressed by this document.
This section classifies the issues that are created by the deployment of encrypted DNS protocols and/or by the change of resolution architectures on the client side, and presents recommendations to address them.
With network-level name resolution, users are in charge of the choice of the resolver used by all their applications. Advanced and educated users make full use of that opportunity, and choose to send their DNS queries to an operator they trust, either by configuring a specific resolver in the operating system or on the router that manages their home network, or as part of a broader traffic encryption and redirection service (e.g. VPNs). Other users will just rely on the local network's server; for home users, this will be provided by their Internet access provider, which they also picked, thus giving them at least some degree of trust. A different, less trusted relationship exists when users that did not configure a specific server connect to a local network which is not their own, for example in Internet cafes or hotels; in that case, they may be led to use a resolver which they do not trust.
Also, in the absence of encryption, the local network operator could still be able to track or even alter the DNS queries and replies that the user has directed to a non-local resolver. Unless this has been agreed with the user or is mandated by applicable legislation, this would be a breach of the user's trust and is a good reason to promote the adoption of encrypted DNS protocols.
With application-level name resolution, and especially with application-level resolver selection, users lose at least part of their control. Some applications may actually not give the user any choice, and just use their own resolver all the times; some others may provide configuration options, but still direct the queries to their own resolver as a default, requiring specific action for users to keep their DNS traffic going to the resolver that they already configured in the operating system.
Such a change of default behaviour would break the expectations of many users; unless appropriate communication is given and consent is acquired, both the users that explicitly configured a resolver in the operating system, and the users that want their device to use the local network's resolver, will be surprised by the application sending DNS queries to another server instead. On the other hand, for less technical users that trust the application maker to make a better choice of resolvers on their behalf, the new behaviour could be in line with their expectations.
However, also given the high sensitivity of the personal information embedded in DNS queries, it is important to ensure that it is ultimately the user, rather than any third party, that determines where their DNS queries should go, and explicitly consents to any choice of resolver that cannot be expected, or to delegating the choice to another party.
This leads to the following recommendations:
For recommendation #2, it may happen that the resolver configured in the operating system does not support encrypted DNS protocols. In this case, the application SHOULD first of all try to determine whether the operator of the non-encrypted resolver that would be used by the operating system also provides any encrypted DNS resolver, through standardized discovery mechanisms such as [I-D.ietf-doh-resolver-associated-doh]; in that case, it SHOULD use that operator's encrypted resolver instead of the unencrypted one.
For recommendation #4, the guidelines in [I-D.ietf-dprive-bcp-op] SHOULD be followed; applications could explore ways to make them more understandable to average Internet users, for example through the use of standardized visual aids. At the same time, due to the complexity and changing nature of this information, applications could simply provide links to where the operator makes it available; a standardized and automated way for resolvers to make this information available to applications would be desirable.
For recommendation #5, in most operating systems and devices it is yet to be discussed how to achieve the objective of letting the user set the preferred resolver and protocol in all the applications at once; the principle, however, deserves to be stated as a recommended direction for future development.
Currently, with network-level name resolution, DNS resolution activities are globally spread across a huge number of resolvers, possibly in the range of the hundreds of thousands or even millions. Users that keep the default of using the local network's resolver see their personal DNS queries spread across multiple servers as they move; users that configure a specific public resolver have their queries concentrated on a single resolver system, but they can pick one that they trust.
However, in many cases, the global market for user applications is much more consolidated than the global market for Internet access and for DNS resolution services. More specifically, estimates for the global browser market currently show one maker having around 60% of the market, and the first four together having over 90% of it. While these market shares may change in the future, the presence of one or a few dominant browsers has almost always been the case since the advent of mass usage of the World Wide Web.
As application-level name resolution turns the application maker into a potential gatekeeper in the choice of the resolver, there is a concern that each application maker could lead its users to the adoption of one specific resolver operator, or limit their choice to a few options that the maker has picked for its own reasons.
While it is understandable that an application maker may want to help its users make a good choice of resolver by using its technical expertise to evaluate and select a narrow set of recommended resolvers, this practice would open opportunities for misuse, as applications could recommend resolvers not because of a fair evaluation, but because of an existing business partnership in the mutual economic interest, or even because the resolver is run directly by the application maker.
In the end, this could lead to a dramatic consolidation of global name resolution operators, with a few server systems managing the broad majority of global resolutions. This, in turn, would have several negative consequences, which will be discussed in the following sections of the document.
However, consolidation is an architectural problem in itself; the Internet was designed to be as decentralized as possible, to increase its resilience and ultimately the freedom of its users. The concern over the centralizing effect of encrypted DNS protocols has been recorded for example in [I-D.arkko-iab-internet-consolidation], section 2.5, and has to be addressed by preventing the use of a strong position in the market for a specific type of client application, especially a ubiquitous one such as browsers, to centralize DNS resolutions and establish a strong position in DNS name resolution services.
This would already be addressed by the recommendations in section 4.1, but it also leads to the following additional recommendations:
If each application could pick a different resolver, there is a chance that different applications would receive different replies to the same DNS queries, leading to confusing user experiences, potential attack surfaces and network management and debugging problems, and in the end to the fragmentation of the Internet into non fully interoperable chunks.
The only way to prevent any occurrence of this case would be to require all applications on the same device to use the same resolver, as in the current network-level resolution model; however, such requirement would be considered too restrictive. Recommendations #2 and #3 in section 4.1 are however meant to make this case a special exception, rather than the norm, and thus mitigate this problem.
However, when allowing different applications to use different resolvers, there is a situation that would significantly endanger the stability of the Internet. Currently, as the application and the resolver are generally provided by two independent entities, and as the application cannot know in advance which resolver will be used, applications cannot rely on predetermined non-standard behaviour by a specific resolver. With application-level resolver selection, applications that enjoy a significant market share could direct users to resolvers that employ alternate DNS namespaces that they control, or start to create and remove top level domains outside of the collectively agreed policy frameworks.
The global uniqueness of the DNS namespace and its collective policy-making procedures should be preserved, and this leads to the following additional recommendation:
Regarding recommendation #1, there may be specific use cases in which a user may want to use an alternate namespace and root server set, and applications, if they want, should be free to support them; however, these cases must be exceptions and not for mainstream usage.
Protecting the user's privacy is the primary aim of transitioning the DNS to encrypted communications. However, risks to privacy deriving from DNS communications are not limited to the eavesdropping of unencrypted DNS communications; [I-D.bortzmeyer-dprive-rfc7626-bis] lists, in section 2.4.2, several privacy risks that still exist even when DNS communications are encrypted; and, in section 2.5.1, it describes the risks that derive from the behaviour of the resolver in use, independently from whether the connection is encrypted or not.
To address the former category of privacy risks, some have suggested that, through the use of DNS-over-HTTPS, the user's requests could be hidden within unrelated HTTPS traffic, locating DNS-over-HTTPS servers at the same IP address and port of widely used web servers. However, this method creates security and legal issues that are documented in the following sections of this document, and so it is not recommended unless the privacy gain is tantamount in respect to any other consideration, for example because of the extreme sensitivity of the online activity or because of a hostile environment that could lead to significant personal risks.
In all other cases, users that feel the need for further obfuscation of their encrypted DNS communication should rather be directed to spreading their communications across a great number of encrypted resolvers, as per recommendation #2 of section 4.2, making it harder to track the entirety of their DNS exchanges.
To address the latter category of privacy risks, the first and foremost mitigation measure is to allow each user to pick a resolver that is managed by an organization that they trust, under appropriate regulatory conditions, privacy policies and operational practices. While "privacy-friendly" applications might (and, indeed, should) help users in making this choice, there is not a unique, globally applicable agreement on what constitutes a "privacy-friendly" resolver, and it is hard to ensure that all application makers will always make disinterested choices in the pure interest of the user; so it must be the user, in the end, to decide who to entrust with their personal information. The recommendations in sections 4.1 and 4.2 thus also contribute to mitigate this type of risks.
In addition, specific technical recommendations can be made to prevent applications from adopting practices that would make it easier for the resolver operator to track and fingerprint the user, mirroring the ones that have been developed in [I-D.ietf-dprive-bcp-op] section 5:
For recommendation #1, and for DNS-over-TLS, a discussion of resolver authentication methods and possibilities can be found in [RFC8310].
For recommendation #2, additional considerations on privacy when using HTTPS as a transport mechanism for other protocols can be found in section 6.1 of [I-D.ietf-httpbis-bcp56bis].
DNS name resolution services are commonly chosen as a platform to control user access to content; while there are other mechanisms in use, checking and blocking destinations at the DNS level is an effective and relatively inexpensive one. As a consequence, the choice of the resolver also determines whether the user will be able to access certain destinations on not, depending on the policies applied by the individual resolver.
Sometimes, on unencrypted DNS connections, content control policies will also be applied to DNS connections directed to other resolvers having a different policy than the local network's one, though this is made impossible by the switch to encrypted DNS connections.
The motivations, the procedures, and the types of content subject to blocking are very variable. Some of the filtering activities are meant to increase the security and health of the network; they can be aimed at non-human clients, such as bots, trying to prevent them from connecting to their command and control servers; or they can try to prevent unaware users from connecting to phishing and malware websites.
Other filtering activities are meant to make some content inaccessible because it violates the law in the user's and/or the resolver's jurisdiction, or because of court rulings that mandate the block. In authoritarian countries, content may be blocked to prevent criticism of the ruling entity, while in democratic countries it can be blocked to defend the safety and rights of some parties and prevent violence and attacks on democracy. Destinations may also be made inaccessible, independently from their content, for lack of compliance with any applicable regulation, such as requirements for licenses or the payment of taxes in the user's country.
The opinions on the appropriateness of these practices are highly influenced by local culture, history and socio-political environments, as well as by each individual's set of values, and it is thus impossible to make blanket recommendations on whether and when they should be forbidden, allowed, or actively supported; the only possible recommendation is to follow the applicable regulations.
In some cases, however, users actually demand DNS-based content control services to shape their own Internet access: for example, families that want to make sure that their children using the Internet from home cannot access inappropriate websites; businesses that want to restrict the way their employees can use the Internet in the office during working hours.
This leads to the following recommendations:
Further considerations on the relationship between applications and applicable legislation will be made in section 4.7.
Network management and network security practices often rely on checks and policies implemented at the DNS level, through the monitoring and mangling of the DNS queries that the users of the local network send to the local resolver. For example, these practices include checking for any unusual patterns in DNS traffic to detect devices that have been infected with malware; blocking queries for known botnet command-and-control servers to make it impossible for bots to communicate with them and take orders; implementing a content control list of web destinations that the network administrator considers dangerous; associating certain names to different IP addresses, some of which may be private, depending on the client and on its topological location; creating names in special use or non-standard top level domains and making them resolvable only from the inside of the local network.
Especially the use of local names and "split horizon" configurations is a widely used security practice in corporate network environments; using a resolver located outside of the network would break this mechanism and at the same time leak information that would be very valuable to an attacker.
These practices rely on forcing all the users of the local network to use the local resolver, rather than a remote public resolver; this requirement is generally enforced through one or more of the following practices:
The switch to encrypted DNS connections makes practice c) generally impossible; the switch to application-level resolver selection also makes a) impossible, unless the network administrator can prevent the installation of any application on all the devices connected to the network, which is not easily feasible in most cases. Finally, the implementation of "mixed mode" DNS-over-HTTPS, obfuscating the traffic within ordinary HTTPS connections to widely used web hosts, would make also practice b) impossible.
So, the deployment of encrypted DNS over dedicated connections disables c), but still leaves a) and b) as options to network administrators; however, the deployment of DNS-over-HTTPS in mixed mode disables all three practices and leaves the network administrators powerless; additionally, it even provides an undetectable data exfiltration vector for malicious applications that are trying to steal confidential information from the local network and forward it to the outside.
While disabling control by the local network administrator might actually be a positive intent in very specific cases, disabling all these security practices at once is dangerous and inappropriate in most cases. It is especially problematic on private networks that host sensitive or commercially valuable information, as they need to be able to provide some degree of connectivity to the Internet while scrutinizing and limiting its usage to guarantee security.
Noting that even [RFC7258], in section 2, stresses that "Making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome", and calls for "an appropriate balance" between encryption and network management needs, the following recommendations, in addition to those in section 4.1., represent such balance:
Further reasons supporting recommendation #1 can be found in sections 4.4 and 4.7.
The current prevailing practice of using local resolvers, located topologically near to the user, generally ensures that the resolver and the user fall under the same jurisdiction. This allows the country managing such jurisdiction to apply rules and policies to the user's Internet access by acting upon the resolver, recommending or mandating actions to the ISP that runs the resolver.
The use of remote resolvers, in most cases located in a different country and under a different jurisdiction than the user, has already provided a way for users to bypass their local laws. Many countries have tolerated this loss of sovereignty because it only affected a minority of users, possibly smarter technical users that could have anyway found other ways to bypass national rules applied at the resolver level, such as running their own recursive resolver. Other countries have instead engaged in enforcing their Internet access rules at other levels, such as by requiring firewalls at each connection between any national network and the broader Internet and filtering out destinations by IP address, or requiring the ISPs to apply similar blocks on each user's Internet connectivity.
In [RFC7754], the IETF has recommended the use of filtering at the endpoints, rather than inside the network, to address issues that require access control to Internet destinations; but filtering at the edges is much harder to set up and to enforce for countries, and the same RFC agrees that "a hybrid approach that combines endpoint-based filtering with network filtering may prove least damaging". In this regard, making resolver-level law-mandated filtering policies impossible is anyway likely to push more countries to mandate heavier, more damaging filtering practices at the IP address level.
From the user's viewpoint, a change in jurisdiction may be beneficial or damaging, depending on which issues are most important for the user and on the applicable legislation in the user's and, if different, in the resolver's country. Users located in jurisdictions that restrict their rights may actively seek to use a resolver in a different jurisdiction to bypass the restrictions. Users that enjoy a high degree of rights in their country, such as extended protections for privacy and network neutrality, may reject the use of a resolver in another jurisdiction not to lose such protections.
It is out of scope for the IETF to decide whether the policies and laws of any country should be supported or opposed. By leaving as much control as possible to the user, as recommended in section 4.1, each user is allowed to decide whether to seek the use of a resolver in a different jurisdiction or stay within their own, bearing the responsibility for any legal consequence that might derive from that decision; and it is important that such a decision is not taken lightly and especially is not taken by the application without telling the user, as the user could otherwise unwillingly end up in legal troubles.
At the same time, while individual users and individual application makers may have different views and follow other practices, it is inappropriate for the IETF as a whole to promote the deployment of technologies in a way that is explicitly designed to undermine any country's sovereignty and jurisdiction. This is another reason to support recommendation #1 in section 4.6 and recommendation #2 in section 4.5. More generally, the following recommendations can be devised:
Remote resolvers rely on global Internet connectivity to be able to serve users from every part of the world. However, there may be cases in which long distance Internet connectivity is so poor to make the use of remote resolvers ineffective, or has been greatly reduced or even completely severed by the effects of natural disasters, upstream legal and contractual issues or any other special situation.
In these cases, it is important that applications can continue working if connectivity to a local resolver can be established, as the resolver, even with global connectivity issues, can still provide access to much needed local resources.
This leads to the following recommendation:
Functioning DNS resolution is a requirement to make Internet connectivity work, and, when it does not, most users have a hard time discerning the specific technical factor that prevents it from working. As they generally acquire their Internet connectivity from a local ISP, they will thus contact the ISP's support desk whenever the connectivity does not work, regardless of the actual cause. However, if the application is using a remote resolver, the ISP's support desk will not be able to know whether such resolver is experiencing operational issues or applying policies that make the user's desired action fail.
It is thus important that application makers, remote resolver operators and ISPs cooperate to allow users to get support on their Internet access problems. For what regards applications, this leads to the following recommendations:
The use of encrypted DNS protocols is beneficial to security as it prevents unauthorized third parties from altering the DNS queries and replies, but it also creates new security risks by disrupting a number of existing and commonly used practices for network security, and by providing, under certain conditions, a mechanism for data exfiltration from within a network through the submission of appropriately designed DNS queries.
More detailed security considerations can be found in section 4.6 of this document.
The use of encrypted DNS protocols in itself is beneficial to privacy as it prevents eavesdropping of the connection. However, the issues created by the deployment model can lead to an overall loss of privacy, for example because the user is led to adopt a resolver operator that offers less privacy protection than the one they are currently using, or that is located under a jurisdiction that offers less privacy protection.
Issues specifically related to privacy, and recommendations to address them, are discussed in section 4.4 of this document.
[ to be written ]
This document has no actions for IANA.
[ to be written ]
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [I-D.arkko-iab-internet-consolidation] | Arkko, J., Trammell, B., Nottingham, M., Huitema, C., Thomson, M. and J. Tantsura, "Considerations on Internet Consolidation and the Internet Architecture", Internet-Draft draft-arkko-iab-internet-consolidation-00, October 2018. |
| [I-D.bortzmeyer-dprive-rfc7626-bis] | Bortzmeyer, S. and S. Dickinson, "DNS Privacy Considerations", Internet-Draft draft-bortzmeyer-dprive-rfc7626-bis-02, January 2019. |
| [I-D.ietf-doh-resolver-associated-doh] | Hoffman, P., "Associating a DoH Server with a Resolver", Internet-Draft draft-ietf-doh-resolver-associated-doh-02, March 2019. |
| [I-D.ietf-dprive-bcp-op] | Dickinson, S., Overeinder, B., Rijswijk-Deij, R. and A. Mankin, "Recommendations for DNS Privacy Service Operators", Internet-Draft draft-ietf-dprive-bcp-op-01, December 2018. |
| [I-D.ietf-httpbis-bcp56bis] | Nottingham, M., "Building Protocols with HTTP", Internet-Draft draft-ietf-httpbis-bcp56bis-08, November 2018. |
| [RFC1034] | Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987. |
| [RFC2131] | Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997. |
| [RFC7258] | Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014. |
| [RFC7754] | Barnes, R., Cooper, A., Kolkman, O., Thaler, D. and E. Nordmark, "Technical Considerations for Internet Service Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, March 2016. |
| [RFC7858] | Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D. and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016. |
| [RFC8310] | Dickinson, S., Gillmor, D. and T. Reddy, "Usage Profiles for DNS over TLS and DNS over DTLS", RFC 8310, DOI 10.17487/RFC8310, March 2018. |
| [RFC8484] | Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018. |