[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                         V. Bertola
Internet-Draft                                              Open-Xchange
Intended status: Informational                        September 10, 2019
Expires: March 13, 2020


          Recommendations for DNS Privacy Client Applications
                    draft-bertola-bcp-doh-clients-01

Abstract

   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.

Status of This Memo

   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 March 13, 2020.

Copyright Notice

   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



Bertola                  Expires March 13, 2020                 [Page 1]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Notation and Conventions . . . . . . . . . . . .   3
   3.  Architectures for Name Resolution Services  . . . . . . . . .   3
   4.  Issues and Recommendations  . . . . . . . . . . . . . . . . .   5
     4.1.  Trust Model and User Choice . . . . . . . . . . . . . . .   5
     4.2.  Consolidation . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Competition and Network Neutrality  . . . . . . . . . . .   9
     4.4.  Namespace Fragmentation . . . . . . . . . . . . . . . . .  10
     4.5.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.6.  Content Access Control  . . . . . . . . . . . . . . . . .  12
     4.7.  Security and Network Management . . . . . . . . . . . . .  13
     4.8.  Jurisdiction  . . . . . . . . . . . . . . . . . . . . . .  15
     4.9.  Disaster Recovery . . . . . . . . . . . . . . . . . . . .  17
     4.10. User Support  . . . . . . . . . . . . . . . . . . . . . .  17
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  18
   7.  Human Rights Considerations . . . . . . . . . . . . . . . . .  18
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     10.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   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.




Bertola                  Expires March 13, 2020                 [Page 2]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   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.

2.  Requirements Notation and Conventions

   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.

3.  Architectures for Name Resolution Services

   It is possible for a device to perform full DNS name resolution on
   its own, without relying on any recursive DNS resolver - indeed, this
   was often the case in the early usage of the DNS.

   However, since when the Internet became a mass affair, the DNS name
   resolution service in consumer Internet access services 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




Bertola                  Expires March 13, 2020                 [Page 3]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   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:

   1.  All the applications on the same device use the same resolver,
       through a library provided by the operating system;

   2.  By default, the device will automatically discover and use the
       resolver provided by the local network;

   3.  The user is in charge of deciding which resolver will be used,
       either by silently accepting the default, or by setting a
       specific resolver in the device configuration.

   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:

   1.  Each application will use its own resolver, bypassing the library
       provided by the operating system;

   2.  No automatic discovery of resolvers on the local network is
       performed;

   3.  The application is in charge of determining which resolver will
       be used, which could be different than the one configured in the
       operating system, and can direct this choice by selecting and
       providing one as the default for all users globally, or even by
       limiting the user's choice to a list of resolvers vetted by the
       application maker.

   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".





Bertola                  Expires March 13, 2020                 [Page 4]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   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.

4.  Issues and Recommendations

   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.

4.1.  Trust Model and User Choice

   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



Bertola                  Expires March 13, 2020                 [Page 5]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   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:

   1.  Users MUST have the final word on which resolver is used by each
       application.

   2.  Applications MUST NOT use a different resolver operator than the
       one that would be used by the operating system, unless the user
       has actively told the application to use a different resolver
       operator and has given explicit and informed consent to the
       change.

   3.  Applications MUST provide users with a configuration mechanism
       that allows them to tell the application to use any resolver the
       user wants.

   4.  Applications SHOULD provide users with adequate information on
       the location, ownership, data management policies and operational
       practices of each resolver, at least for the resolvers that they
       provide as hard-coded configuration options.

   5.  Applications SHOULD support, if available, easy ways for the user
       to direct all applications on the device to use a specific
       resolver and a specific protocol, without the need to configure
       them one by one.



Bertola                  Expires March 13, 2020                 [Page 6]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   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.

4.2.  Consolidation

   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;
   while some consolidation is happening, mostly into some big remote
   resolver platforms, still it takes the thousand biggest resolvers to
   aggreagate 90% of global DNS traffic.  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



Bertola                  Expires March 13, 2020                 [Page 7]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   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:

   1.  Applications MUST NOT prioritize any specific resolver over
       others unless told so by the user, or design their user
       interaction to lead users towards choosing a specific resolver or
       one of a few specific resolvers.

   2.  If possible, and if desired by the user, applications SHOULD
       provide ways to spread their DNS resolution traffic across the
       highest possible number of recursive resolvers.  [NOTE: this
       recommendation is actually a placeholder, as there are drawbacks
       to this idea and other, better methods could be devised - this is
       TBD]

   3.  If applications would like to ensure that their users can pick a
       resolver that has been vetted under a set of criteria, the
       definition, verification and enforcement of these criteria SHOULD



Bertola                  Expires March 13, 2020                 [Page 8]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


       be deferred to an independent multi-stakeholder organization,
       making these criteria public and objective and giving any
       resolver operator from any part of the Internet a fair chance to
       be admitted to the list of vetted services; in any case, users
       MUST still be free to adopt servers outside of the vetted list if
       they so desire.

4.3.  Competition and Network Neutrality

   The possible inception of a stricter relationship between application
   makers and resolver operators also creates issues related to
   competition, which can in turn have effects on the architecture and
   performance of the network and on its capacity for permissionless
   innovation, and compromise the neutrality of network transport, as
   DNS resolution is a fundamental step in establishing any network
   connection.

   In addition to the consolidation effect described in the previous
   section, any relationship between the application maker and a
   resolver operator that could lead the application to direct users to
   a specific resolver could be used to reduce the opportunities
   available to other resolver operators, including innovative ones, and
   even to other application makers, for example by virtue of exclusive
   service agreements.  This can be a likely case when the application
   maker and the resolver operator are the same entity, but it could
   happen also when the application maker and the resolver operator are
   two different entities that have established a business partnership
   in the mutual interest.

   Another case of anti-competitive effect could happen when the
   resolver operator also operates another service that depends for its
   effectiveness on the results of the DNS resolution process - for
   example, content delivery networks.  Resolver operators that also
   operate CDNs could provide slower or less effective DNS resolution
   for access to content distributed by their competitors.

   While this matter will also be under the purview of national and
   international market regulations, there are some recommendations - in
   addition to those in the previous section, that also address this
   issue - that can be made in terms of best practices, to neutralize as
   far as possible any direct relationship between the application maker
   and the resolver operator:

   [ to be discussed ]







Bertola                  Expires March 13, 2020                 [Page 9]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


4.4.  Namespace Fragmentation

   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:

   1.  Applications SHOULD NOT adopt alternate DNS namespaces or promote
       the use of resolvers that do not rely on the global DNS root
       server system.

   2.  Applications SHOULD NOT deviate from the DNS namespace management
       policies, technical standards and operational practices that are
       defined in the relevant Internet governance venues.

   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.







Bertola                  Expires March 13, 2020                [Page 10]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


4.5.  Privacy

   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 must prevail upon 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.  Moreover, if privacy
   is so important, users should consider that they also need to encrypt
   the rest of the communications, and not just the resolution of domain
   names; thus, using a VPN for all their traffic might just be easier
   and better.

   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,



Bertola                  Expires March 13, 2020                [Page 11]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   mirroring the ones that have been developed in
   [I-D.ietf-dprive-bcp-op] section 5:

   1.  Applications MUST authenticate the resolver they connect to, if
       they have securely discovered the information required to do so.

   2.  In the case of DNS-over-HTTPS, applications SHOULD NOT attach or
       receive HTTP cookies on the connections used for the DNS message
       exchange, unless there is a specific use case for cookies that
       has been explicitly requested by the user.

   3.  [to be continued]

   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].

4.6.  Content Access Control

   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



Bertola                  Expires March 13, 2020                [Page 12]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   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:

   1.  Applications MUST NOT prevent users from using any DNS-based
       content control service that they freely choose to adopt.

   2.  Applications SHOULD comply with any legislation and legal ruling
       on content control that applies to them in the jurisdiction where
       they are being used.

   Further considerations on the relationship between applications and
   applicable legislation will be made in section 4.7.

4.7.  Security and Network Management

   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.



Bertola                  Expires March 13, 2020                [Page 13]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   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:

   a.  Making sure that all devices that are connected to the local
       network are configured to use the local resolver, disallowing the
       users from modifying this configuration entry;

   b.  Blocking access to remote resolvers at the edge of the local
       network, for example through firewalls and blocks by destination
       IP address and/or port;

   c.  Examining, and if necessary amending, all DNS queries and replies
       in transit towards remote resolvers.

   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.




Bertola                  Expires March 13, 2020                [Page 14]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   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:

   1.  Applications SHOULD NOT adopt the practice of hiding their
       encrypted DNS traffic in ways that prevent the local network
       administrator from isolating it, monitoring it (without breaking
       the encryption) and, if desired, blocking it; exceptions to this
       principle MUST be motivated by a clear and compelling use case
       which cannot be addressed otherwise, and their use MUST be
       limited to such use case.  [Note: of course I am sure that many
       people will want to discuss this - the idea is to not stop this
       from happening when it is really useful, but also restrict its
       usage to when it is really useful, leaving network admins with
       the possibility to block external encrypted resolvers if they
       want, without starting a technical "arms race".]

   2.  [to be continued]

   Further reasons supporting recommendation #1 can be found in sections
   4.5 and 4.8.

4.8.  Jurisdiction

   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.





Bertola                  Expires March 13, 2020                [Page 15]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   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.7 and recommendation #2 in
   section 4.6.  More generally, the following recommendations can be
   devised:

   1.  Applications SHOULD clearly inform the user whenever the resolver
       that it is going to be employed lies under a jurisdiction
       different than the one of the user.

   2.  Applications SHOULD NOT adopt a resolver located under a
       jurisdiction different than the user's one, unless the user has
       explicitly consented to such change of jurisdiction, and unless




Bertola                  Expires March 13, 2020                [Page 16]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


       the user's jurisdiction allows the use of resolvers located in a
       different country.

4.9.  Disaster Recovery

   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:

   1.  Applications, when using a remote resolver, SHOULD monitor the
       availability of sufficient connectivity to it, and SHOULD prompt
       the user to switch temporarily to a local resolver, if available,
       when such connectivity is not available.

4.10.  User Support

   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:

   1.  Applications SHOULD make it easy for users to determine whether
       any failure that they experience in the use of the application
       can be attributed to a failure in DNS resolution.






Bertola                  Expires March 13, 2020                [Page 17]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   2.  Applications SHOULD cooperate with remote resolver operators to
       direct users that experience problems due to resolver failures to
       the support service of the resolver operator.

   3.  Applications SHOULD provide easy ways for their users to retrieve
       the information on the resolver currently in use, so that they
       can pass on this information to whoever is helping them to
       restore their connectivity.

5.  Security Considerations

   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.7 of
   this document.

6.  Privacy Considerations

   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.5 of this document.

7.  Human Rights Considerations

   [ to be written ]

8.  IANA Considerations

   This document has no actions for IANA.

9.  Acknowledgements

   [ to be written ]





Bertola                  Expires March 13, 2020                [Page 18]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

10.2.  Informative References

   [I-D.arkko-iab-internet-consolidation]
              Arkko, J., Trammell, B., Nottingham, M., Huitema, C.,
              Thomson, M., Tantsura, J., and N. Oever, "Considerations
              on Internet Consolidation and the Internet Architecture",
              draft-arkko-iab-internet-consolidation-02 (work in
              progress), July 2019.

   [I-D.bortzmeyer-dprive-rfc7626-bis]
              Bortzmeyer, S. and S. Dickinson, "DNS Privacy
              Considerations", draft-bortzmeyer-dprive-rfc7626-bis-02
              (work in progress), January 2019.

   [I-D.ietf-doh-resolver-associated-doh]
              Hoffman, P., "Associating a DoH Server with a Resolver",
              draft-ietf-doh-resolver-associated-doh-03 (work in
              progress), March 2019.

   [I-D.ietf-dprive-bcp-op]
              Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A.
              Mankin, "Recommendations for DNS Privacy Service
              Operators", draft-ietf-dprive-bcp-op-03 (work in
              progress), July 2019.

   [I-D.ietf-httpbis-bcp56bis]
              Nottingham, M., "Building Protocols with HTTP", draft-
              ietf-httpbis-bcp56bis-08 (work in progress), November
              2018.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <https://www.rfc-editor.org/info/rfc2131>.





Bertola                  Expires March 13, 2020                [Page 19]


Internet-Draft     DNS Privacy Client Recommendations     September 2019


   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/info/rfc7258>.

   [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, <https://www.rfc-editor.org/info/rfc7754>.

   [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, <https://www.rfc-editor.org/info/rfc7858>.

   [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,
              <https://www.rfc-editor.org/info/rfc8310>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

Author's Address

   Vittorio Bertola
   Open-Xchange
   Via Treviso 12
   Torino  10144
   Italy

   Email: vittorio.bertola@open-xchange.com
   URI:   https://www.open-xchange.com


















Bertola                  Expires March 13, 2020                [Page 20]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/