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



Network Working Group                                            N. Cook
Internet-Draft                                                V. Bertola
Intended status: Informational                              Open-Xchange
Expires: January 14, 2021                                      A. Fidler
                                                                  BT plc
                                                              N. Leymann
                                                        Deutsche Telekom
                                                                R. Weber
                                                                  Akamai
                                                           July 13, 2020


                  A Proposal for a DoH Discovery Trial
                   draft-cook-doh-discovery-trial-00

Abstract

   The following document describes a proposal for a trial of an
   experimental mechanism for the discovery of DNS-over-HTTPS resolvers
   provided by Internet Service Providers to their customers.

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 January 14, 2021.

Copyright Notice

   Copyright (c) 2020 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



Cook, et al.            Expires January 14, 2021                [Page 1]


Internet-Draft             DoH Discovery Trial                 July 2020


   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.

1.  Introduction

   The introduction of encrypted DNS transport protocols like DoH (DNS-
   over-HTTPS [RFC8484]) can provide additional confidentiality to
   Internet users that need a DNS resolution service to access online
   resources.  Most end-users currently get their DNS resolution service
   from the Internet Service Provider that also supplies them with
   Internet access; thus, to promote a straightforward migration path
   from unencrypted to encrypted DNS transport and to avoid the issues
   deriving from a change of DNS provider, it would be useful to
   establish a mechanism through which stub DNS resolvers on the user's
   device can discover under appropriate security conditions whether the
   local network provides a DoH resolver, and if so, start using it
   automatically.  This DoH deployment model will be referred to as
   "same provider auto-upgrade".

   This document describes an experimental mechanism which was developed
   by a group of Internet Service Providers and DNS implementers for
   that use case, based on the use of a DNS query for a special use
   domain name.  It is intended as an informational document to support
   and encourage other parties to join the experiment.

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

   The IETF ADD Working Group was approved by the IESG in February 2020;
   an extract from the charter [ADD] follows:

   "This working group will focus on discovery and selection of DNS
   resolvers by DNS clients in a variety of networking environments,
   including public networks, private networks, and VPNs, supporting
   both encrypted and unencrypted resolvers.  It is chartered solely to
   develop technical mechanisms.  Making any recommendations about
   specific policies for clients or servers is out of scope."



Cook, et al.            Expires January 14, 2021                [Page 2]


Internet-Draft             DoH Discovery Trial                 July 2020


   To support the achievement of this technical objective, non-technical
   considerations also come into play.  There is a desire to maximise
   the number of users that can enjoy an easy upgrade path towards DNS
   encryption, by making it possible for customers of ISPs that deploy
   DoH interfaces to their resolvers to get upgraded automatically.

   The early discovery mechanisms implemented by some browsers cannot
   cope with home networks advertising the CPE's private IP address as
   the endpoint for the local DNS resolver, and thus would exclude the
   fixed broadband and home mobile router customers of a significant
   number of ISPs (including the major ones in Europe) from access to
   this new technology, depending on their Internet access network
   architecture and on their ease of upgrade of CPEs.

   Additionally, in Europe regulation requires all ISPs to allow users
   to connect to the Internet with any home router of their choice, so
   it is not even possible for ISPs to prevent the use of home routers
   that do not support any other DNS resolver mode than dnsmasq over a
   private IP address.

   Regardless of the outcome of IETF and policy discussions, it is
   likely that any fully fledged, standard discovery protocol will take
   a relatively long time to reach consensus.  Therefore this document
   proposes an interim solution, which combines in-band discovery with
   out-of-band protections such as those already used by Google Chrome
   and Microsoft Windows (i.e. pre-vetting of DoH services, plus some
   additional protections as discussed below).

   This solution would allow participating ISPs using DNS forwarders in
   their CPEs to provide DoH resolver services to their users in a short
   timeframe, as long as they used clients (browsers and operating
   systems) that participate in this trial.

   The proposed solution is described in the following section.

4.  The Proposed DoH Discovery Trial

4.1.  How ISPs Join the Trial

   Out-of-band (e.g. through the already established process, or through
   direct contact at industry venues such as EDDI [EDDI]), ISPs make it
   known that they would like client vendors to discover their DoH
   service, but have a significant proportion of users who are using
   CPEs which act as forwarders.

   Each participating vendor, depending on their own security policies,
   decides if they are fine with an open DNS-based discovery of the
   local resolver, or if they want to reduce the potential attack



Cook, et al.            Expires January 14, 2021                [Page 3]


Internet-Draft             DoH Discovery Trial                 July 2020


   surface by restricting the resolvers that the local network can
   advertise.  Section 5.2. describes the security implications of such
   a choice.

   In the latter case, participating ISPs, regardless of whether they
   plan to offer public DoH services, guarantee that they (also) offer a
   DoH service on a URI which is closed, i.e. only accessible from their
   own network and not from the Internet, and whose hostname is located
   within a domain name owned by the ISP; this is the DoH service that
   can be enrolled in the program for vendors that require such
   restriction.  We will refer to these DoH services as "closed
   resolvers".

   This restriction prevents malicious actors from switching a user's
   DNS resolution to an off-net DNS resolver which is also a trial
   participant.  (However it does not prevent switching from an off-net
   to an on-net resolver; see section 5).  It is up to each DoH client
   vendor whether they choose to validate (once or continuously) such a
   guarantee.

   The ISPs then provide the vendors with the URI(s) of their
   (optionally closed) DoH service(s).  The URI must contain an FQDN; IP
   addresses are not acceptable.  These URIs are added to a list
   maintained by the DoH client vendor.  For the purposes of this
   document, we shall call this list the "whitelist" of DoH servers
   corresponding to ISP resolvers reached via CPEs; it could be a
   different list from the list of public DoH services used by the
   current auto-upgrade mechanisms.

4.2.  Proposed DoH Resolver Discovery Logic

   This process only starts if the configured Do53 resolver is a private
   ([RFC 1918]) IPv4 or IPv6 link local or unique local address.  The
   auto-upgrade of resolvers with public IP addresses is outside of the
   scope of this document, though participating vendors, if they want,
   can use this mechanism for that purpose as well.

   The client performs over Do53 (traditional DNS) a TXT record lookup
   for dohresolver.arpa, a specifically chosen special use domain name
   (SUDN) [RFC6761].  Eventually, if this mechanism gains adoption, it
   may be appropriate to register this name with IANA, but we do not
   anticipate any problems using it on an interim basis, since it is
   restricted to specific resolvers and does not affect the wider DNS or
   the arpa TLD.  Also, it would be easy to move to any other SUDN that
   might be standardized by the IETF.

   The resolver is configured to respond to that SUDN with a TXT record
   containing the URI template of the DoH service.



Cook, et al.            Expires January 14, 2021                [Page 4]


Internet-Draft             DoH Discovery Trial                 July 2020


   If the Do53 response is anything other than a TXT answer, the
   discovery is terminated.  As a note, some browser makers reported
   that they sometimes have difficulties with performing lookups on DNS
   records other than A/AAAA.  If CPE routinely filter/drop TXT record
   lookups, then this approach will not work.  To our knowledge, none of
   the CPE of the ISPs providing data for this document do any
   modification or filtering of TXT records, and common forwarding
   software such as dnsmasq does not appear to have issues with
   arbitrary RRs.  Any more facts on this topic would be useful.

   In the event of no response being received, the client should decide
   its own retry policy for the dohresolver.arpa query, but we recommend
   one or more retries are performed to mitigate packet loss or
   temporary high load.

   In the event of a successful response, the client - if so desires -
   can check whether the URI in the response matches one of the
   (optionally closed) DoH URIs that have been added to the "whitelist",
   and discard it if not.

   In the event of a successful response which points to an acceptable
   DoH resolver, it is up to the DoH client vendor what happens next,
   for example:

   o  Auto-upgrade takes place - i.e. connection is attempted to that
      URI.  Assuming that certificate validation and TLS handshake
      succeeds etc., resolution switches to the DoH service, otherwise
      the client continues to use the Do53 service.

   o  The user is presented with a dialog asking them if they'd like to
      use the newly discovered DoH server.  If they accept, then
      connection proceeds as above.

   o  The DoH server is added to a list of manually selectable DoH
      servers.

   o  Any other suitable logic, e.g. ignoring the response for policy
      reasons.

   The DoH client should respect the TTL of the TXT record returned, and
   perform a new DNS lookup upon expiry.

4.3.  Effect on Possible Use Cases

   The basic policy principle for the existing auto-upgrade methods is
   to avoid changing the resolver that the user has chosen either
   explicitly (i.e. through manual configuration) or implicitly (e.g.
   via DHCP).



Cook, et al.            Expires January 14, 2021                [Page 5]


Internet-Draft             DoH Discovery Trial                 July 2020


   This logic attempts to preserve that as far as practically possible,
   through use of the TXT record lookup; the lookup will only return a
   valid answer if the resolver being used has actively created an
   authoritative TXT record for the dohresolver.arpa domain.  This
   assumes no malicious actors; see section 5 for security
   considerations.

   We will now discuss the impact of running such an experiment in real
   world use cases, showing the behaviour that will occur for customers
   of participating ISPs using participating clients if the DoH client
   follows the logic described in this proposal.  The four possible
   scenarios for a consumer setup cover all the possible variations of
   resolver/forwarder configuration and downstream resolver.  If either
   the ISP or the client does not participate in the experiment, no
   auto-upgrade will ever happen.

   This is the effect of the proposed logic in the different scenarios:

   1.  The user is using an ISP-supplied CPE, which forwards Do53
       traffic to the ISP's Do53 resolver.  The ISP's Do53 resolver will
       return a TXT record for dohresolver.arpa, and thus auto-upgrade
       will take place.  The client will then bypass the forwarder,
       directing queries via DoH directly to the ISP's resolver.

   2.  The user manually configured a local DNS forwarder themselves
       (e.g. an off-the-shelf CPE, or they run dnsmasq on a local
       server) to forward queries to their local ISP resolver.  This
       resolver will return a TXT record for dohresolver.arpa, and thus
       auto-upgrade will take place, bypassing the forwarder, exactly
       like in the previous case.

   3.  The user has manually configured a local DNS forwarder themselves
       (e.g. an off-the-shelf CPE, or they have modified the ISP-
       provided CPE) to forward to a resolver that is not the ISP
       resolver, e.g. 1.1.1.1 or 9.9.9.9.  These resolvers will return
       NXDOMAIN for dohresolver.arpa, and thus no auto-upgrade will take
       place.

   4.  The user has manually configured a local DNS resolver themselves
       (e.g.  Raspberry PI or similar).  This resolver will return
       NXDOMAIN for dohresolver.arpa, and thus no auto-upgrade will take
       place.

   From the DoH client's perspective, all four scenarios are the same
   (i.e. the system resolver has a RFC1918 IPv4 or IPv6 link local or
   unique local address), and whether that resolver was configured via
   DHCP or manually would not appear to matter that much.  Scenarios 3




Cook, et al.            Expires January 14, 2021                [Page 6]


Internet-Draft             DoH Discovery Trial                 July 2020


   and 4 can be discounted because no action takes place, however
   scenarios 1 and 2 do have the effect of bypassing the forwarder.

   There is a semantic difference between scenarios 1 and 2; in scenario
   2 the user may have configured a forwarder deliberately, for example
   to do filtering, caching, logging or innumerable other reasons.  For
   that reason, DoH client vendors need to consider whether the above
   scenarios, (or any additional scenarios not considered above),
   justify asking for the user's consent to the upgrade to DoH directly
   to the ISP resolver (and thus bypassing any intermediate forwarders).

   Moreover, in cases 3 and 4 it would be easy for the operator of the
   alternative resolver (whether it is another DNS operator, as in case
   3, or the user themselves, as in case 4) to also allow auto-upgrade
   to DoH of the connection, simply by configuring their own resolver to
   reply to the query for dohresolver.arpa.  However, if the client
   vendor chooses to restrict the auto-upgrade mechanism only to
   whitelisted URIs, then these other operators would need to also join
   the experiment; in case 3, this could be made impossible by the
   restriction itself, as by definition the resolver in this case is an
   "open" one, and the vendor would need to partially lift the
   restriction and accept known open DoH resolvers from a separate
   whitelist; in case 4, this could be made impossible by the non-
   technical requirements of the procedure for joining.

5.  Security Considerations

5.1.  Existing Auto-Upgrade Mechanisms

   The security objective for current same-provider auto-upgrade
   mechanisms is to ensure that the client is talking to the same
   resolver operator as before, but now over DoH.  On-path attackers
   have no way to influence this, since the mechanism is based on the
   client knowing the public IP address of the existing resolver and a
   pre-configured URI template for the auto-upgrade DoH resolver for
   that IP address.

5.2.  Current Proposal

   This proposal does not use the same threat model as the existing
   auto-upgrade solution.  The differences are discussed below.

   On-path attackers could perform a downgrade attack.  However, given
   that current auto-upgrade mechanisms do not work for users with
   forwarders in their CPE, such a downgrade attack would result in the
   same situation as currently, i.e. the client would continue to use
   Do53.  However, given this threat, the upgrade to DoH can only be
   considered as opportunistic security.



Cook, et al.            Expires January 14, 2021                [Page 7]


Internet-Draft             DoH Discovery Trial                 July 2020


   On-path attackers could change the discovery response from that
   returned by the actual configured resolver.  There are two scenarios
   that need to be considered, depending on the vendor's policy.

   If the DoH client vendor enforces the "closed resolver" restriction,
   then the following applies:

   o  Given that the client will only accept auto-upgrade via discovery
      to a "closed resolver", there is only one resolver that will be
      accepted by the client via the discovery mechanism - the DoH
      resolver offered by the user's ISP.  (This assumes that the ISP is
      diligent about ensuring their resolver is actually closed - this
      could be verified periodically by the vendors).

   o  There exists a risk that an on-path attacker could redirect a user
      from a manually selected resolver (configured manually by the user
      on the CPE/forwarder) to the resolver provided by the local ISP.
      This would have the effect of moving the user from a resolver that
      they did select (e.g. 9.9.9.9) to one they did not select.  Such a
      risk is not mitigated by this proposal.  Note that this risk
      exists only when there is an on-path attacker, since the discovery
      query happens via DNS and thus goes to the resolver originally
      chosen by the user.

   If the DoH client vendor does not enforce the "closed resolver"
   restriction, then the following applies.  An on-path attacker could
   redirect a user from a manually selected resolver (configured
   manually by the user on the CPE/forwarder) to any resolver on the
   "whitelist" of DoH servers.  This would have the effect of moving the
   user from a resolver that they did select to one they did not select.
   Such a risk is not mitigated by this proposal.  Note that this risk
   exists only when there is an on-path attacker, since the discovery
   query happens via DNS and thus goes to the resolver originally chosen
   by the user.

   In both of the above use cases, the only possible end result of a
   successful attack aimed at changing resolvers is that a user has
   moved from an insecure Do53 service whose results are controlled by a
   malicious on-path attacker, to a secure DoH service which is on the
   DoH client's "whitelist".  The on-path attacker has only succeeded in
   moving the user to a vendor-verified resolver over which they have no
   control, and which they cannot use for further attacks; as long as
   the vendor's whitelisting process is secure, an attacker wishing to
   gain control of the user's DNS resolution process for further steps,
   e.g. to redirect the user's Web requests to a phishing page, would
   not be able to do so through this attack.  This would apply even if
   the new DoH resolver were open, as long as it is on (the same or
   another) vendor-verified whitelist.  However, the user has still



Cook, et al.            Expires January 14, 2021                [Page 8]


Internet-Draft             DoH Discovery Trial                 July 2020


   moved to a resolver operated by a different organization which is
   almost certainly not what the user "wanted"; hence the possible need
   for user confirmation.

   The security assumptions regarding the "closed resolvers" above are
   predicated on the participating ISPs performing the appropriate
   actions to "close" their resolver(s) to the public internet, thus
   making them only available to customers on their network.  DoH client
   vendors relying on the security assumptions provided by this may wish
   to make periodic checks (see section 6) to ensure that listed DoH
   resolvers are indeed not accessible from the public internet,
   otherwise new attacks would be possible such as an on-path attacker
   redirecting a user from their currently selected resolver to the
   resolver of another participating ISP.

   In the end, vendors that adopt the approach of vetting and
   whitelisting DoH resolvers before allowing users to auto-upgrade to
   them will always enjoy a certain degree of reassurance on the
   legitimacy of those resolvers (though at the expense of excluding the
   users of other DoH resolvers, including self-managed resolvers that
   people may install on their home networks, from automatic upgrade).

   Without the additional "closed resolver" restriction, an attacker may
   succeed in redirecting the user to any of the whitelisted DoH
   services, while with that additional restriction, an attacker may
   only succeed in redirecting the user to the ISP's own closed DoH
   service, if the user is not already using it.  Whether this gain in
   security is worth the additional organizational complexity is for
   each vendor to consider; we expect that running this experiment could
   also allow to evaluate how useful that additional restriction could
   be in practice.

6.  Implications for Vendors

   The experiment requires participating vendors to change their current
   implementation of the auto-upgrade mechanism and add the logic
   described.

   For DoH client vendors enforcing the "closed resolver" restriction,
   some additional vetting and active checking of "auto-upgrade" DoH
   providers would be necessary, to ensure that ISP resolvers are indeed
   "closed" and only accessible to customers on their own networks, as
   assumed in Section 5 above.  This could take the form of periodic
   attempts to connect to all the DoH URIs on the "whitelist" from a
   variety of locations known to be outside of any service provider
   networks.  It would be up to the organisation responsible for the DoH
   client to decide how stringent this check should be.  For example, it




Cook, et al.            Expires January 14, 2021                [Page 9]


Internet-Draft             DoH Discovery Trial                 July 2020


   may involve automated weekly checks, and alerts to ISPs whose
   resolvers do not meet the required standards.

   DoH client vendors who also support the "auto-upgrade based on public
   resolver IP" logic need to maintain two "whitelists"; DoH servers
   could of course be on both lists, or both lists could be merged into
   one with additional parameters for each featured resolver, as
   preferred.

7.  Acknowledgements

   This document is the product of an informal group of experts
   including the following people:

      Alister Winfield, Sky

      Andrew Campling, 419 Consulting

      Andy Fidler, BT plc

      Chris Box, BT plc

      Gianpaolo Scalone, Vodafone

      Neil Cook, Open-Xchange

      Nic Leymann, Deutsche Telekom

      Norman Kowalewski, Deutsche Telekom

      Ralf Weber, Akamai

      Vittorio Bertola, Open-Xchange

   The authors would like to thank Kenji Baheux and Eric Orth (Google)
   and Tommy Jensen (Microsoft) for their feedback and suggestions.

8.  References

8.1.  Normative References

   [ADD]      IETF, "Adaptive DNS Discovery (ADD) Working Group",
              February 2020,
              <https://datatracker.ietf.org/wg/add/about/>.







Cook, et al.            Expires January 14, 2021               [Page 10]


Internet-Draft             DoH Discovery Trial                 July 2020


   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <https://www.rfc-editor.org/info/rfc1918>.

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

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <https://www.rfc-editor.org/info/rfc6761>.

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

8.2.  Informative References

   [EDDI]     EDDI, "Encrypted DNS Deployment Initiative", July 2020,
              <https://www.encrypted-dns.org/>.

Authors' Addresses

   Neil Cook
   Open-Xchange Ltd
   7 Gerard Street
   Ashton-in-Makerfield, Wigan, Greater Manchester  WN4 9AG
   United Kingdom

   Email: neil.cook@noware.co.uk
   URI:   https://www.open-xchange.com/


   Vittorio Bertola
   Open-Xchange Srl
   Via Treviso 12
   Torino  10144
   Italy

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








Cook, et al.            Expires January 14, 2021               [Page 11]


Internet-Draft             DoH Discovery Trial                 July 2020


   Andy Fidler
   BT plc
   BT Adastral Park
   Martlesham Heath, Ipswich  IP5 3RE
   United Kingdom

   Email: andrew.fidler@bt.com
   URI:   https://www.bt.com/


   Nicolai Leymann
   Deutsche Telekom AG
   Friedrich-Ebert-Allee 140
   Bonn  53113
   Germany

   Email: N.Leymann@telekom.de
   URI:   https://www.telekom.com/


   Ralf Weber
   Akamai Technologies GmbH
   Parkring 20-22
   Garching  85748
   Germany

   Email: ralf.weber@akamai.com
   URI:   https://www.akamai.com/























Cook, et al.            Expires January 14, 2021               [Page 12]


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