idnits 2.17.00 (12 Aug 2021)
/tmp/idnits58224/draft-cook-doh-discovery-trial-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
== There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 13, 2020) is 670 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'RFC 1918' is mentioned on line 177, but not defined
== Unused Reference: 'RFC1918' is defined on line 479, but no explicit
reference was found in the text
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group N. Cook
3 Internet-Draft V. Bertola
4 Intended status: Informational Open-Xchange
5 Expires: January 14, 2021 A. Fidler
6 BT plc
7 N. Leymann
8 Deutsche Telekom
9 R. Weber
10 Akamai
11 July 13, 2020
13 A Proposal for a DoH Discovery Trial
14 draft-cook-doh-discovery-trial-00
16 Abstract
18 The following document describes a proposal for a trial of an
19 experimental mechanism for the discovery of DNS-over-HTTPS resolvers
20 provided by Internet Service Providers to their customers.
22 Status of This Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at https://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on January 14, 2021.
39 Copyright Notice
41 Copyright (c) 2020 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (https://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 1. Introduction
56 The introduction of encrypted DNS transport protocols like DoH (DNS-
57 over-HTTPS [RFC8484]) can provide additional confidentiality to
58 Internet users that need a DNS resolution service to access online
59 resources. Most end-users currently get their DNS resolution service
60 from the Internet Service Provider that also supplies them with
61 Internet access; thus, to promote a straightforward migration path
62 from unencrypted to encrypted DNS transport and to avoid the issues
63 deriving from a change of DNS provider, it would be useful to
64 establish a mechanism through which stub DNS resolvers on the user's
65 device can discover under appropriate security conditions whether the
66 local network provides a DoH resolver, and if so, start using it
67 automatically. This DoH deployment model will be referred to as
68 "same provider auto-upgrade".
70 This document describes an experimental mechanism which was developed
71 by a group of Internet Service Providers and DNS implementers for
72 that use case, based on the use of a DNS query for a special use
73 domain name. It is intended as an informational document to support
74 and encourage other parties to join the experiment.
76 2. Requirements Notation and Conventions
78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
80 document are to be interpreted as described in [RFC2119].
82 Throughout this document, values are quoted to indicate that they are
83 to be taken literally. When using these values in protocol messages,
84 the quotes MUST NOT be used as part of the value.
86 3. Rationale
88 The IETF ADD Working Group was approved by the IESG in February 2020;
89 an extract from the charter [ADD] follows:
91 "This working group will focus on discovery and selection of DNS
92 resolvers by DNS clients in a variety of networking environments,
93 including public networks, private networks, and VPNs, supporting
94 both encrypted and unencrypted resolvers. It is chartered solely to
95 develop technical mechanisms. Making any recommendations about
96 specific policies for clients or servers is out of scope."
97 To support the achievement of this technical objective, non-technical
98 considerations also come into play. There is a desire to maximise
99 the number of users that can enjoy an easy upgrade path towards DNS
100 encryption, by making it possible for customers of ISPs that deploy
101 DoH interfaces to their resolvers to get upgraded automatically.
103 The early discovery mechanisms implemented by some browsers cannot
104 cope with home networks advertising the CPE's private IP address as
105 the endpoint for the local DNS resolver, and thus would exclude the
106 fixed broadband and home mobile router customers of a significant
107 number of ISPs (including the major ones in Europe) from access to
108 this new technology, depending on their Internet access network
109 architecture and on their ease of upgrade of CPEs.
111 Additionally, in Europe regulation requires all ISPs to allow users
112 to connect to the Internet with any home router of their choice, so
113 it is not even possible for ISPs to prevent the use of home routers
114 that do not support any other DNS resolver mode than dnsmasq over a
115 private IP address.
117 Regardless of the outcome of IETF and policy discussions, it is
118 likely that any fully fledged, standard discovery protocol will take
119 a relatively long time to reach consensus. Therefore this document
120 proposes an interim solution, which combines in-band discovery with
121 out-of-band protections such as those already used by Google Chrome
122 and Microsoft Windows (i.e. pre-vetting of DoH services, plus some
123 additional protections as discussed below).
125 This solution would allow participating ISPs using DNS forwarders in
126 their CPEs to provide DoH resolver services to their users in a short
127 timeframe, as long as they used clients (browsers and operating
128 systems) that participate in this trial.
130 The proposed solution is described in the following section.
132 4. The Proposed DoH Discovery Trial
134 4.1. How ISPs Join the Trial
136 Out-of-band (e.g. through the already established process, or through
137 direct contact at industry venues such as EDDI [EDDI]), ISPs make it
138 known that they would like client vendors to discover their DoH
139 service, but have a significant proportion of users who are using
140 CPEs which act as forwarders.
142 Each participating vendor, depending on their own security policies,
143 decides if they are fine with an open DNS-based discovery of the
144 local resolver, or if they want to reduce the potential attack
145 surface by restricting the resolvers that the local network can
146 advertise. Section 5.2. describes the security implications of such
147 a choice.
149 In the latter case, participating ISPs, regardless of whether they
150 plan to offer public DoH services, guarantee that they (also) offer a
151 DoH service on a URI which is closed, i.e. only accessible from their
152 own network and not from the Internet, and whose hostname is located
153 within a domain name owned by the ISP; this is the DoH service that
154 can be enrolled in the program for vendors that require such
155 restriction. We will refer to these DoH services as "closed
156 resolvers".
158 This restriction prevents malicious actors from switching a user's
159 DNS resolution to an off-net DNS resolver which is also a trial
160 participant. (However it does not prevent switching from an off-net
161 to an on-net resolver; see section 5). It is up to each DoH client
162 vendor whether they choose to validate (once or continuously) such a
163 guarantee.
165 The ISPs then provide the vendors with the URI(s) of their
166 (optionally closed) DoH service(s). The URI must contain an FQDN; IP
167 addresses are not acceptable. These URIs are added to a list
168 maintained by the DoH client vendor. For the purposes of this
169 document, we shall call this list the "whitelist" of DoH servers
170 corresponding to ISP resolvers reached via CPEs; it could be a
171 different list from the list of public DoH services used by the
172 current auto-upgrade mechanisms.
174 4.2. Proposed DoH Resolver Discovery Logic
176 This process only starts if the configured Do53 resolver is a private
177 ([RFC 1918]) IPv4 or IPv6 link local or unique local address. The
178 auto-upgrade of resolvers with public IP addresses is outside of the
179 scope of this document, though participating vendors, if they want,
180 can use this mechanism for that purpose as well.
182 The client performs over Do53 (traditional DNS) a TXT record lookup
183 for dohresolver.arpa, a specifically chosen special use domain name
184 (SUDN) [RFC6761]. Eventually, if this mechanism gains adoption, it
185 may be appropriate to register this name with IANA, but we do not
186 anticipate any problems using it on an interim basis, since it is
187 restricted to specific resolvers and does not affect the wider DNS or
188 the arpa TLD. Also, it would be easy to move to any other SUDN that
189 might be standardized by the IETF.
191 The resolver is configured to respond to that SUDN with a TXT record
192 containing the URI template of the DoH service.
194 If the Do53 response is anything other than a TXT answer, the
195 discovery is terminated. As a note, some browser makers reported
196 that they sometimes have difficulties with performing lookups on DNS
197 records other than A/AAAA. If CPE routinely filter/drop TXT record
198 lookups, then this approach will not work. To our knowledge, none of
199 the CPE of the ISPs providing data for this document do any
200 modification or filtering of TXT records, and common forwarding
201 software such as dnsmasq does not appear to have issues with
202 arbitrary RRs. Any more facts on this topic would be useful.
204 In the event of no response being received, the client should decide
205 its own retry policy for the dohresolver.arpa query, but we recommend
206 one or more retries are performed to mitigate packet loss or
207 temporary high load.
209 In the event of a successful response, the client - if so desires -
210 can check whether the URI in the response matches one of the
211 (optionally closed) DoH URIs that have been added to the "whitelist",
212 and discard it if not.
214 In the event of a successful response which points to an acceptable
215 DoH resolver, it is up to the DoH client vendor what happens next,
216 for example:
218 o Auto-upgrade takes place - i.e. connection is attempted to that
219 URI. Assuming that certificate validation and TLS handshake
220 succeeds etc., resolution switches to the DoH service, otherwise
221 the client continues to use the Do53 service.
223 o The user is presented with a dialog asking them if they'd like to
224 use the newly discovered DoH server. If they accept, then
225 connection proceeds as above.
227 o The DoH server is added to a list of manually selectable DoH
228 servers.
230 o Any other suitable logic, e.g. ignoring the response for policy
231 reasons.
233 The DoH client should respect the TTL of the TXT record returned, and
234 perform a new DNS lookup upon expiry.
236 4.3. Effect on Possible Use Cases
238 The basic policy principle for the existing auto-upgrade methods is
239 to avoid changing the resolver that the user has chosen either
240 explicitly (i.e. through manual configuration) or implicitly (e.g.
241 via DHCP).
243 This logic attempts to preserve that as far as practically possible,
244 through use of the TXT record lookup; the lookup will only return a
245 valid answer if the resolver being used has actively created an
246 authoritative TXT record for the dohresolver.arpa domain. This
247 assumes no malicious actors; see section 5 for security
248 considerations.
250 We will now discuss the impact of running such an experiment in real
251 world use cases, showing the behaviour that will occur for customers
252 of participating ISPs using participating clients if the DoH client
253 follows the logic described in this proposal. The four possible
254 scenarios for a consumer setup cover all the possible variations of
255 resolver/forwarder configuration and downstream resolver. If either
256 the ISP or the client does not participate in the experiment, no
257 auto-upgrade will ever happen.
259 This is the effect of the proposed logic in the different scenarios:
261 1. The user is using an ISP-supplied CPE, which forwards Do53
262 traffic to the ISP's Do53 resolver. The ISP's Do53 resolver will
263 return a TXT record for dohresolver.arpa, and thus auto-upgrade
264 will take place. The client will then bypass the forwarder,
265 directing queries via DoH directly to the ISP's resolver.
267 2. The user manually configured a local DNS forwarder themselves
268 (e.g. an off-the-shelf CPE, or they run dnsmasq on a local
269 server) to forward queries to their local ISP resolver. This
270 resolver will return a TXT record for dohresolver.arpa, and thus
271 auto-upgrade will take place, bypassing the forwarder, exactly
272 like in the previous case.
274 3. The user has manually configured a local DNS forwarder themselves
275 (e.g. an off-the-shelf CPE, or they have modified the ISP-
276 provided CPE) to forward to a resolver that is not the ISP
277 resolver, e.g. 1.1.1.1 or 9.9.9.9. These resolvers will return
278 NXDOMAIN for dohresolver.arpa, and thus no auto-upgrade will take
279 place.
281 4. The user has manually configured a local DNS resolver themselves
282 (e.g. Raspberry PI or similar). This resolver will return
283 NXDOMAIN for dohresolver.arpa, and thus no auto-upgrade will take
284 place.
286 From the DoH client's perspective, all four scenarios are the same
287 (i.e. the system resolver has a RFC1918 IPv4 or IPv6 link local or
288 unique local address), and whether that resolver was configured via
289 DHCP or manually would not appear to matter that much. Scenarios 3
290 and 4 can be discounted because no action takes place, however
291 scenarios 1 and 2 do have the effect of bypassing the forwarder.
293 There is a semantic difference between scenarios 1 and 2; in scenario
294 2 the user may have configured a forwarder deliberately, for example
295 to do filtering, caching, logging or innumerable other reasons. For
296 that reason, DoH client vendors need to consider whether the above
297 scenarios, (or any additional scenarios not considered above),
298 justify asking for the user's consent to the upgrade to DoH directly
299 to the ISP resolver (and thus bypassing any intermediate forwarders).
301 Moreover, in cases 3 and 4 it would be easy for the operator of the
302 alternative resolver (whether it is another DNS operator, as in case
303 3, or the user themselves, as in case 4) to also allow auto-upgrade
304 to DoH of the connection, simply by configuring their own resolver to
305 reply to the query for dohresolver.arpa. However, if the client
306 vendor chooses to restrict the auto-upgrade mechanism only to
307 whitelisted URIs, then these other operators would need to also join
308 the experiment; in case 3, this could be made impossible by the
309 restriction itself, as by definition the resolver in this case is an
310 "open" one, and the vendor would need to partially lift the
311 restriction and accept known open DoH resolvers from a separate
312 whitelist; in case 4, this could be made impossible by the non-
313 technical requirements of the procedure for joining.
315 5. Security Considerations
317 5.1. Existing Auto-Upgrade Mechanisms
319 The security objective for current same-provider auto-upgrade
320 mechanisms is to ensure that the client is talking to the same
321 resolver operator as before, but now over DoH. On-path attackers
322 have no way to influence this, since the mechanism is based on the
323 client knowing the public IP address of the existing resolver and a
324 pre-configured URI template for the auto-upgrade DoH resolver for
325 that IP address.
327 5.2. Current Proposal
329 This proposal does not use the same threat model as the existing
330 auto-upgrade solution. The differences are discussed below.
332 On-path attackers could perform a downgrade attack. However, given
333 that current auto-upgrade mechanisms do not work for users with
334 forwarders in their CPE, such a downgrade attack would result in the
335 same situation as currently, i.e. the client would continue to use
336 Do53. However, given this threat, the upgrade to DoH can only be
337 considered as opportunistic security.
339 On-path attackers could change the discovery response from that
340 returned by the actual configured resolver. There are two scenarios
341 that need to be considered, depending on the vendor's policy.
343 If the DoH client vendor enforces the "closed resolver" restriction,
344 then the following applies:
346 o Given that the client will only accept auto-upgrade via discovery
347 to a "closed resolver", there is only one resolver that will be
348 accepted by the client via the discovery mechanism - the DoH
349 resolver offered by the user's ISP. (This assumes that the ISP is
350 diligent about ensuring their resolver is actually closed - this
351 could be verified periodically by the vendors).
353 o There exists a risk that an on-path attacker could redirect a user
354 from a manually selected resolver (configured manually by the user
355 on the CPE/forwarder) to the resolver provided by the local ISP.
356 This would have the effect of moving the user from a resolver that
357 they did select (e.g. 9.9.9.9) to one they did not select. Such a
358 risk is not mitigated by this proposal. Note that this risk
359 exists only when there is an on-path attacker, since the discovery
360 query happens via DNS and thus goes to the resolver originally
361 chosen by the user.
363 If the DoH client vendor does not enforce the "closed resolver"
364 restriction, then the following applies. An on-path attacker could
365 redirect a user from a manually selected resolver (configured
366 manually by the user on the CPE/forwarder) to any resolver on the
367 "whitelist" of DoH servers. This would have the effect of moving the
368 user from a resolver that they did select to one they did not select.
369 Such a risk is not mitigated by this proposal. Note that this risk
370 exists only when there is an on-path attacker, since the discovery
371 query happens via DNS and thus goes to the resolver originally chosen
372 by the user.
374 In both of the above use cases, the only possible end result of a
375 successful attack aimed at changing resolvers is that a user has
376 moved from an insecure Do53 service whose results are controlled by a
377 malicious on-path attacker, to a secure DoH service which is on the
378 DoH client's "whitelist". The on-path attacker has only succeeded in
379 moving the user to a vendor-verified resolver over which they have no
380 control, and which they cannot use for further attacks; as long as
381 the vendor's whitelisting process is secure, an attacker wishing to
382 gain control of the user's DNS resolution process for further steps,
383 e.g. to redirect the user's Web requests to a phishing page, would
384 not be able to do so through this attack. This would apply even if
385 the new DoH resolver were open, as long as it is on (the same or
386 another) vendor-verified whitelist. However, the user has still
387 moved to a resolver operated by a different organization which is
388 almost certainly not what the user "wanted"; hence the possible need
389 for user confirmation.
391 The security assumptions regarding the "closed resolvers" above are
392 predicated on the participating ISPs performing the appropriate
393 actions to "close" their resolver(s) to the public internet, thus
394 making them only available to customers on their network. DoH client
395 vendors relying on the security assumptions provided by this may wish
396 to make periodic checks (see section 6) to ensure that listed DoH
397 resolvers are indeed not accessible from the public internet,
398 otherwise new attacks would be possible such as an on-path attacker
399 redirecting a user from their currently selected resolver to the
400 resolver of another participating ISP.
402 In the end, vendors that adopt the approach of vetting and
403 whitelisting DoH resolvers before allowing users to auto-upgrade to
404 them will always enjoy a certain degree of reassurance on the
405 legitimacy of those resolvers (though at the expense of excluding the
406 users of other DoH resolvers, including self-managed resolvers that
407 people may install on their home networks, from automatic upgrade).
409 Without the additional "closed resolver" restriction, an attacker may
410 succeed in redirecting the user to any of the whitelisted DoH
411 services, while with that additional restriction, an attacker may
412 only succeed in redirecting the user to the ISP's own closed DoH
413 service, if the user is not already using it. Whether this gain in
414 security is worth the additional organizational complexity is for
415 each vendor to consider; we expect that running this experiment could
416 also allow to evaluate how useful that additional restriction could
417 be in practice.
419 6. Implications for Vendors
421 The experiment requires participating vendors to change their current
422 implementation of the auto-upgrade mechanism and add the logic
423 described.
425 For DoH client vendors enforcing the "closed resolver" restriction,
426 some additional vetting and active checking of "auto-upgrade" DoH
427 providers would be necessary, to ensure that ISP resolvers are indeed
428 "closed" and only accessible to customers on their own networks, as
429 assumed in Section 5 above. This could take the form of periodic
430 attempts to connect to all the DoH URIs on the "whitelist" from a
431 variety of locations known to be outside of any service provider
432 networks. It would be up to the organisation responsible for the DoH
433 client to decide how stringent this check should be. For example, it
434 may involve automated weekly checks, and alerts to ISPs whose
435 resolvers do not meet the required standards.
437 DoH client vendors who also support the "auto-upgrade based on public
438 resolver IP" logic need to maintain two "whitelists"; DoH servers
439 could of course be on both lists, or both lists could be merged into
440 one with additional parameters for each featured resolver, as
441 preferred.
443 7. Acknowledgements
445 This document is the product of an informal group of experts
446 including the following people:
448 Alister Winfield, Sky
450 Andrew Campling, 419 Consulting
452 Andy Fidler, BT plc
454 Chris Box, BT plc
456 Gianpaolo Scalone, Vodafone
458 Neil Cook, Open-Xchange
460 Nic Leymann, Deutsche Telekom
462 Norman Kowalewski, Deutsche Telekom
464 Ralf Weber, Akamai
466 Vittorio Bertola, Open-Xchange
468 The authors would like to thank Kenji Baheux and Eric Orth (Google)
469 and Tommy Jensen (Microsoft) for their feedback and suggestions.
471 8. References
473 8.1. Normative References
475 [ADD] IETF, "Adaptive DNS Discovery (ADD) Working Group",
476 February 2020,
477 .
479 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
480 and E. Lear, "Address Allocation for Private Internets",
481 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
482 .
484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
485 Requirement Levels", BCP 14, RFC 2119,
486 DOI 10.17487/RFC2119, March 1997,
487 .
489 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
490 RFC 6761, DOI 10.17487/RFC6761, February 2013,
491 .
493 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
494 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
495 .
497 8.2. Informative References
499 [EDDI] EDDI, "Encrypted DNS Deployment Initiative", July 2020,
500 .
502 Authors' Addresses
504 Neil Cook
505 Open-Xchange Ltd
506 7 Gerard Street
507 Ashton-in-Makerfield, Wigan, Greater Manchester WN4 9AG
508 United Kingdom
510 Email: neil.cook@noware.co.uk
511 URI: https://www.open-xchange.com/
513 Vittorio Bertola
514 Open-Xchange Srl
515 Via Treviso 12
516 Torino 10144
517 Italy
519 Email: vittorio.bertola@open-xchange.com
520 URI: https://www.open-xchange.com/
521 Andy Fidler
522 BT plc
523 BT Adastral Park
524 Martlesham Heath, Ipswich IP5 3RE
525 United Kingdom
527 Email: andrew.fidler@bt.com
528 URI: https://www.bt.com/
530 Nicolai Leymann
531 Deutsche Telekom AG
532 Friedrich-Ebert-Allee 140
533 Bonn 53113
534 Germany
536 Email: N.Leymann@telekom.de
537 URI: https://www.telekom.com/
539 Ralf Weber
540 Akamai Technologies GmbH
541 Parkring 20-22
542 Garching 85748
543 Germany
545 Email: ralf.weber@akamai.com
546 URI: https://www.akamai.com/