idnits 2.17.1 draft-ietf-dprive-unilateral-probing-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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (7 March 2022) is 781 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'X' is mentioned on line 841, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-10 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-14 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive D.K. Gillmor 3 Internet-Draft ACLU 4 Intended status: Informational J. Salazar 5 Expires: 8 September 2022 7 March 2022 7 Unilateral Opportunistic Deployment of Encrypted Recursive-to- 8 Authoritative DNS 9 draft-ietf-dprive-unilateral-probing-00 11 Abstract 13 This draft sets out steps that DNS servers (recursive resolvers and 14 authoritative servers) can take unilaterally (without any 15 coordination with other peers) to defend DNS query privacy against a 16 passive network monitor. The steps in this draft can be defeated by 17 an active attacker, but should be simpler and less risky to deploy 18 than more powerful defenses. The draft also introduces (but does not 19 try to specify) the semantics of signalling that would permit defense 20 against an active attacker. 22 The goal of this draft is to simplify and speed deployment of 23 opportunistic encrypted transport in the recursive-to-authoritative 24 hop of the DNS ecosystem. With wider easy deployment of the 25 underlying transport on an opportunistic basis, we hope to facilitate 26 the future specification of stronger cryptographic protections 27 against more powerful attacks. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 8 September 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Priorities . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Minimizing Negative Impacts . . . . . . . . . . . . . . . 4 67 2.2. Protocol Choices . . . . . . . . . . . . . . . . . . . . 4 68 3. Guidance for Authoritative Servers . . . . . . . . . . . . . 5 69 3.1. Pooled Authoritative Servers Behind a Single IP 70 Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 5 72 3.3. Server Name Indication . . . . . . . . . . . . . . . . . 6 73 3.4. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 6 74 4. Guidance for recursive resolvers . . . . . . . . . . . . . . 7 75 4.1. Overall recursive resolver Settings . . . . . . . . . . . 7 76 4.2. Recursive Resolver Requirements . . . . . . . . . . . . . 8 77 4.3. Authoritative Server Encrypted Transport Connection 78 State . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 4.3.1. Separate State for Each of the Recursive Resolver's Own 80 IP Addresses . . . . . . . . . . . . . . . . . . . . 10 81 4.4. Maintaining Authoritative State by IP Address . . . . . . 10 82 4.5. Probing Policy . . . . . . . . . . . . . . . . . . . . . 11 83 4.5.1. Sending a query over Do53 . . . . . . . . . . . . . . 11 84 4.5.2. Receiving a response over Do53 . . . . . . . . . . . 12 85 4.5.3. Initiating a connection over encrypted transport . . 12 86 4.5.4. Establishing an encrypted transport connection . . . 14 87 4.5.5. Failing to establish an encrypted transport 88 connection . . . . . . . . . . . . . . . . . . . . . 15 89 4.5.6. Encrypted transport failure . . . . . . . . . . . . . 15 90 4.5.7. Handling clean shutdown of encrypted transport 91 connection . . . . . . . . . . . . . . . . . . . . . 16 92 4.5.8. Sending a query over encrypted transport . . . . . . 17 93 4.5.9. Receiving a response over encrypted transport . . . . 17 94 4.5.10. Resource Exhaustion . . . . . . . . . . . . . . . . . 18 95 4.5.11. Maintaining connections . . . . . . . . . . . . . . . 19 96 5. Signalling for Stronger Defense . . . . . . . . . . . . . . . 19 97 5.1. Combining Signals with Opportunistic Probing . . . . . . 20 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 99 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 100 7.1. Server Name Indication . . . . . . . . . . . . . . . . . 20 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 102 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 105 10.2. Informative References . . . . . . . . . . . . . . . . . 21 106 Appendix A. Document Considerations . . . . . . . . . . . . . . 22 107 A.1. Document History . . . . . . . . . . . . . . . . . . . . 23 108 A.1.1. Substantive changes from -01 to -02 . . . . . . . . . 23 109 A.1.2. Substantive changes from -00 to -01 . . . . . . . . . 23 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 112 1. Introduction 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 ([RFC2119] and [RFC8174]) when, and only when, they appear in all 120 capitals, as shown here. 122 1.2. Terminology 124 * "unilateral" means capable of opportunistic probing deployment 125 without external coordination with any of the other parties 127 * Do53 refers to traditional cleartext DNS over port 53 ([RFC1035]) 129 * DoQ refers to DNS-over-QUIC ([I-D.ietf-dprive-dnsoquic]) 131 * DoT refers to DNS-over-TLS ([RFC7858]) 133 * DoH refers to DNS-over-HTTPS ([RFC8484]) 135 * Encrypted transports refers to DoQ, DoT, and DoH collectively 137 2. Priorities 139 This document aims to provide guidance to implementers who want to 140 simply enable protection against passive network observers. 142 In particular, it focuses on mechanisms that can be adopted 143 unilaterally by recursive resolvers and authoritative servers, 144 without any explicit coordination with the other parties. This 145 guidance provides opportunistic security (see [RFC7435]) -- 146 encrypting things that would otherwise be in the clear, without 147 interfering with or weakening stronger forms of security. 149 2.1. Minimizing Negative Impacts 151 It also aims to minimize potentially negative impacts caused by the 152 probing of encrypted transports -- for the systems that adopt these 153 guidelines, for the parties that they communicate with in the "second 154 hump" of the DNS camel, and for uninvolved third parties. The 155 negative impacts that we specifically try to minimize are: 157 * excessive bandwidth use 159 * excessive computational resources (CPU and memory in particular) 161 * amplification attacks (where DNS resolution infrastructure is 162 wielded as part of a DoS attack) 164 2.2. Protocol Choices 166 While this document focuses specifically on strategies used by DNS 167 servers, it does not go into detail on the specific protocols used, 168 as those protocols --- in particular, DoT and DoQ --- are described 169 in other documents. 171 This document does not pursue the use of DoH in this context, because 172 a DoH client needs to know the path part of a DoH endpoint URL, and 173 there are currently no mechanisms for a DNS resolver to predict the 174 path on its own, in an opportunistic or unilateral fashion, without 175 incurring in excessive use of resources. For instance, a recursive 176 resolver in theory could guess the full path to a queried IP address 177 by trying all the URL paths that the client has in records and see if 178 one of those works, but even though it can be expected that this 179 would work 99% of the time with fewer than 100 probes, this technique 180 would likely incur in excessive resource consumption potentially 181 leading to vulnerabilities and amplification attacks. The authors of 182 this draft particularly welcome ideas and contributions from the 183 community that lead to a suitable mechanism for unilaterally probing 184 for DoH-capable authoritative servers, for later consideration in 185 this or other drafts. 187 3. Guidance for Authoritative Servers 189 An authoritative server SHOULD implement and deploy DNS-over-TLS 190 (DoT) on TCP port 853. 192 An authoritative server MAY implement and deploy DNS-over-QUIC (DoQ) 193 on UDP port 853. 195 3.1. Pooled Authoritative Servers Behind a Single IP Address 197 Some authoritative DNS servers are structured as a pool of 198 authoritatives standing behind a load-balancer that runs on a single 199 IP address, forwarding queries to members of the pool. 201 In such a deployment, individual members of the pool typically get 202 updated independently from each other. 204 A recursive resolver following the guidance in Section 4 that 205 interacts with such a pool likely does not know that it is a pool. 206 If some members of the pool are updated to follow this guidance while 207 others are not, the recursive client might see the pool as a single 208 authoritative server that sometimes offers and sometimes refuses 209 encrypted transport. 211 To avoid incurring additional minor timeouts for such a recursive 212 resolver, the pool operator SHOULD either: 214 * ensure that all members of the pool enable the same encrypted 215 transport(s) within the span of a few seconds, or 217 * ensure that the load balancer maps client requests to pool members 218 based on client IP addresses. 220 Similar concerns apply to authoritative servers responding from an 221 anycast IP address. As long as the pool of servers is in a 222 heterogenous state, any flapping route that switches a given client 223 IP address to a different responder risks incurring an additional 224 timeout. Frequent changes of routing for anycast listening IP 225 addresses are also likely to cause problems for TLS, TCP, or QUIC 226 connection state as well, so stable routes are important to ensure 227 that the service remains available and responsive. 229 3.2. Authentication 231 For unilateral deployment, an authoritative server does not need to 232 offer any particular form of authentication. 234 The simplest deployment would simply provide a self-issued, 235 regularly-updated X.509 certificate. This mechanism is supported by 236 many TLS and QUIC clients, and will be acceptable for any 237 opportunistic connection. 239 Possible alternate forms of server authentication include: 241 * an X.509 Certificate issued by a widely-known certification 242 authority associated with the common NS names used for this 243 authoritative server 245 * DANE authentication (potentially including the TLS handshake) 247 3.3. Server Name Indication 249 An authoritative DNS server that wants to handle unilateral queries 250 MAY rely on Server Name Indication (SNI) to select alternate server 251 credentials. However, such a server MUST NOT serve resource records 252 that differ based on SNI (or on the lack of SNI) provided by the 253 client, as a probing recursive resolver that offers SNI might or 254 might not have used the right server name to get the records it's 255 looking for. 257 3.4. Resource Exhaustion 259 A well-behaved recursive resolver may keep an encrypted connection 260 open to an authoritative server, to amortize the costs of connection 261 setup for both parties. 263 However, some authoritative servers may have insufficient resources 264 available to keep many connections open concurrently. 266 To keep resources under control, authoritative servers should 267 proactively manage their encrypted connections. Section 6.5 of 268 [I-D.ietf-dprive-dnsoquic] ("Connection Handling") offers useful 269 guidance for servers managing DoQ connections. Section 3.4 of 270 [RFC7858] offers useful guidance for servers managing DoT 271 connections. 273 An authoritative server facing unforseen resource exhaustion SHOULD 274 cleanly close open connections from recursive resolvers based on the 275 authoritative's preferred prioritization. 277 In the case of unanticipated resource exhaustion, a reasonable 278 prioritization scheme would be to close connections in this order, 279 until resources are back in control: 281 * connections with no outstanding queries, ordered by idle time 282 (longest idle time gets closed first) 284 * connections with outstanding queries, ordered by age of 285 outstanding query (oldest outstanding query gets closed first) 287 When resources are especially tight, the authoritative server may 288 also decline to accept new connections over encrypted transport. 290 4. Guidance for recursive resolvers 292 This section outlines a probing policy suitable for unilateral 293 adoption by any recursive resolver. Following this policy should not 294 result in failed resolutions or significant delay. 296 4.1. Overall recursive resolver Settings 298 A recursive resolver implementing this draft must set system-wide 299 values for some default parameters. These parameters may be set 300 independently for each supported encrypted transport, though a simple 301 implementation may keep the parameters constant across encrypted 302 transports. 304 +=============+===================================+===========+ 305 | Name | Description | Suggested | 306 | | | Default | 307 +=============+===================================+===========+ 308 | persistence | How long should the recursive | 3 days | 309 | | resolver remember successful | (259200 | 310 | | encrypted transport connections? | seconds) | 311 +-------------+-----------------------------------+-----------+ 312 | damping | How long should the recursive | 1 day | 313 | | resolver remember unsuccessful | (86400 | 314 | | encrypted transport connections? | seconds) | 315 +-------------+-----------------------------------+-----------+ 316 | timeout | How long should the recursive | 4 seconds | 317 | | resolver wait for an initiated | | 318 | | encrypted connection to complete? | | 319 +-------------+-----------------------------------+-----------+ 321 Table 1: recursive resolver system parameters per encrypted 322 transport 324 This document uses the notation E-foo to refer to the foo parameter 325 for the encrypted transport E. 327 For example DoT-persistence would indicate the length of time that 328 the recursive resolver will remember that an authoritative server had 329 a successful connection over DoT. 331 This document also assumes that the resolver maintains a list of 332 outstanding cleartext queries destined for the authoritative 333 resolver's IP address X. This list is referred to as 334 Do53-queries[X]. This document does not attempt to describe the 335 specific operation of sending and receiving cleartext DNS queries 336 (Do53) for a recursive resolver. Instead it describes a "bolt-on" 337 mechanism that extends the recursive resolver's operation on a few 338 simple hooks into the recursive resolver's existing handling of Do53. 340 Implementers or deployers of DNS recursive resolvers that follow the 341 strategies in this document are encouraged to report their preferred 342 values of these parameters. 344 4.2. Recursive Resolver Requirements 346 To follow this guidance, a recursive resolver MUST implement at least 347 one of either DoT or DoQ in its capacity as a client of authoritative 348 nameservers. 350 A recursive resolver SHOULD implement the client side of DNS-over-TLS 351 (DoT). A recursive resolver MAY implement the client side of DNS- 352 over-QUIC (DoQ). 354 DoT queries from the recursive resolver MUST target TCP port 853, 355 with an ALPN of dot. DoQ queries from the recursive resolver MUST 356 target UDP port 853, with an ALPN of doq. 358 While this document focuses on the recursive-to-authoritative hop, a 359 recursive resolver implementing these strategies SHOULD also accept 360 queries from its clients over some encrypted transport (current 361 common transports are DoH or DoT). 363 4.3. Authoritative Server Encrypted Transport Connection State 365 The recursive resolver SHOULD keep a record of the state for each 366 authoritative server it contacts, indexed by the IP address of the 367 authoritative server and the encrypted transports supported by the 368 recursive resolver. 370 Each record should contain the following fields for each supported 371 encrypted transport, each of which would initially be null: 373 +===============+==========================================+========+ 374 | Name | Description | Retain | 375 | | | Across | 376 | | | Reset | 377 +===============+==========================================+========+ 378 | session | The associated state of any | N | 379 | | existing, established session (the | | 380 | | structure of this value is dependent | | 381 | | on the encrypted transport | | 382 | | implementation). If session is not | | 383 | | null, it may be in one of two | | 384 | | states: pending or established | | 385 +---------------+------------------------------------------+--------+ 386 | initiated | Timestamp of most recent connection | Y | 387 | | attempt | | 388 +---------------+------------------------------------------+--------+ 389 | completed | Timestamp of most recent completed | Y | 390 | | handshake | | 391 +---------------+------------------------------------------+--------+ 392 | status | Enumerated value of success or fail | Y | 393 | | or timeout, associated with the | | 394 | | completed handshake | | 395 +---------------+------------------------------------------+--------+ 396 | resumptions | A stack of resumption tickets (and | Y | 397 | | associated parameters) that could be | | 398 | | used to resume a prior successful | | 399 | | connection | | 400 +---------------+------------------------------------------+--------+ 401 | queries | A queue of queries intended for this | N | 402 | | authoritative server, each of which | | 403 | | has additional status early, unsent, | | 404 | | or sent | | 405 +---------------+------------------------------------------+--------+ 406 | last-activity | A timestamp of the most recent | N | 407 | | activity on the connection | | 408 +---------------+------------------------------------------+--------+ 410 Table 2: recursive resolver state per authoritative IP, per encrypted 411 transport 413 Note that the session fields in aggregate constitute a pool of open 414 connections to different servers. 416 With the exception of the session, queries, and last-activity fields, 417 this cache information should be kept across restart of the server 418 unless explicitly cleared by administrative action. 420 This document uses the notation E-foo[X] to indicate the value of 421 field foo for encrypted transport E to IP address X. 423 For example, DoT-initiated[192.0.2.4] represents the timestamp when 424 the most recent DoT connection packet was sent to IP address 425 192.0.2.4. 427 4.3.1. Separate State for Each of the Recursive Resolver's Own IP 428 Addresses 430 Note that the recursive resolver should record this per- 431 authoritative-IP state for each IP address it uses as it sends its 432 queries. For example, if a recursive resolver can send a packet to 433 authoritative servers from IP addresses 192.0.2.100 and 192.0.2.200, 434 it should keep two distinct sets of per-authoritative-IP state, one 435 for each source address it uses. Keeping these state tables distinct 436 for each source address makes it possible for a pooled authoritative 437 server behind a load balancer to do a partial rollout while 438 minimizing accidental timeouts (see Section 3.1). 440 4.4. Maintaining Authoritative State by IP Address 442 In designing a probing strategy, the recursive resolver could record 443 its knowledge about any given authoritative server with different 444 strategies, including at least: 446 * the authoritative server's IP address, 448 * the authoritative server's name (the NS record used), or 450 * the zone that contains the record being looked up. 452 This draft encourages the first strategy, to minimize timeouts or 453 accidental delays. 455 A timeout (accidental delay) is most likely to happen when the 456 recursive client believes that the authoritative server offers 457 encrypted transport, but the actual server reached declines encrypted 458 transport (or worse, filters the incoming traffic and does not even 459 respond with an ICMP port closed message). 461 By associating state with the IP address, the recursive client is 462 most able to avoid reaching a heterogenous deployment. 464 For example, consider an authoritative server named ns0.example.com 465 that is served by two installations (with two A records), one at 466 192.0.2.7 that follows this guidance, and one at 192.0.2.8 that is a 467 legacy (cleartext port 53-only) deployment. A recursive client who 468 associates state with the NS name and reaches .7 first will "learn" 469 that ns0.example.com supports encrypted transport. A subsequent 470 query over encrypted transport dispatched to .8 would fail, 471 potentially delaying the response. 473 By associating the state with the authoritative IP address, the 474 client can minimize the number of accidental delays introduced (see 475 also Section 4.3.1 and Section 3.1). 477 4.5. Probing Policy 479 When a recursive resolver discovers the need for an authoritative 480 lookup to an authoritative DNS server using IP address X, it 481 retrieves the records associated with X from its cache. 483 The following sections presume that the time of the discovery of the 484 need for lookup is time T0. 486 If any of the records discussed here are absent, they are treated as 487 null. 489 The recursive resolver must know to decide whether to initially send 490 a query over Do53, or over any of the supported encrypted transports 491 (DoT or DoQ). 493 Note that a resolver might initiate this query via any or all of the 494 known transports. When multiple queries are sent, the initial 495 packets for each connection can be sent concurrently, similar to 496 "Happy Eyeballs" ([RFC8305]). However, unlike Happy Eyeballs, when 497 one transport succeeds, the other connections do not need to be 498 terminated, but can instead be continued to establish whether the IP 499 address X is capable of corresponding on the relevant transport. 501 4.5.1. Sending a query over Do53 503 For any of the supported encrypted transports E, if either of the 504 following holds true, the resolver SHOULD NOT send a query to X over 505 Do53: 507 * E-session[X] is in the established state, or 509 * E-status[X] is success, and (T - E-completed[X]) < persistence 511 Otherwise, if there is no outstanding session for any encrypted 512 transport, and the last successful encrypted transport connection was 513 long ago, the resolver sends a query to X over Do53. When it does 514 so, it inserts a handle for the query in Do53-queries[X]. 516 4.5.2. Receiving a response over Do53 518 When a successful response R is received in cleartext from 519 authoritative server X for a query Q that was sent over Do53, the 520 recursive resolver should: 522 * If Q is in Do53-queries[X]: 524 - Return R to the requesting client 526 * Remove Q from Do53-queries[X] 528 * For each supported encrypted transport E: 530 - If Q is in E-queries[X]: 532 o Remove Q from E-queries[X] 534 But if R is unsuccessful (e.g. SERVFAIL): 536 * If Q is in Do53-queries[X]: 538 - Remove Q from Do53-queries[X] 540 * if Q is not in any of *-queries[X]: 542 - Return SERVFAIL to the client 544 4.5.3. Initiating a connection over encrypted transport 546 If any E-session[X] is in the established, the recursive resolver 547 SHOULD NOT initiate a new connection to X over any other transport, 548 but should instead send a query through the existing session (see 549 Section 4.5.8). FIXME: What if there's a preferred transport, but 550 the established session does not correspond to that preferred 551 transport? 553 Otherwise, the timer should examine and possibly refresh its state 554 for encrypted transport E to authoritative IP address X: 556 * if E-session[X] is in state pending, and 558 * T - E-initiated[X] > E-timeout, then 560 - set E-session[X] to null and 562 - set E-status[X] to timeout 564 When resources are available to attempt a new encrypted transport, 565 the resolver should only initiate a new connection to X over E as 566 long as one of the following holds true: 568 * E-status[X] is success, or 570 * E-status[X] is fail or timeout and (T - E-completed[X]) > damping, 571 or 573 * E-status[X] is null and E-initiated[X] is null 575 When initiating a session to X over encrypted transport E, if 576 E-resumptions[X] is not empty, one ticket should be popped off the 577 stack and used to try to resume a previous session. Otherwise, the 578 initial Client Hello handshake should not try to resume any session. 580 When initiating a connection, the resolver should take the following 581 steps: 583 * set E-initiated[X] to T0 585 * store a handle for the new session (which should have pending 586 state) in E-session[X] 588 * insert a handle for the query that prompted this connection in 589 E-queries[X], with status unsent or early, as appropriate (see 590 below). 592 4.5.3.1. Early Data 594 Modern encrypted transports like TLS 1.3 offer the chance to store 595 "early data" from the client into the initial Client Hello in some 596 contexts. A resolver that initiates a connection over a encrypted 597 transport according to this guidance in a context where early data is 598 possible SHOULD send the DNS query that prompted the connection in 599 the early data, according to the sending guidance in Section 4.5.8. 601 If it does so, the status of Q in E-queries[X] should be set to early 602 instead of unsent. 604 4.5.3.2. Resumption Tickets 606 When initiating a new connection (whether by resuming an old session 607 or not), the recursive resolver SHOULD request a session resumption 608 ticket from the authoritative server. If the authoritative server 609 supplies a resumption ticket, the recursive resolver pushes it into 610 the stack at E-resumptions[X]. 612 4.5.3.3. Server Name Indication 614 For modern encrypted transports like TLS 1.3, most client 615 implementations expect to send a Server Name Indication (SNI) in the 616 Client Hello. 618 There are two complications with selecting or sending SNI in this 619 unilateral probing: 621 * Some authoritative servers are known by more than one name; 622 selecting a single name to use for a given connection may be 623 difficult or impossible. 625 * In most configurations, the contents of the SNI field is exposed 626 on the wire to a passive adversary. This potentially reveals 627 additional information about which query is being made, based on 628 the NS of the query itself. 630 To avoid additional leakage and complexity, a recursive resolver 631 following this guidance SHOULD NOT send SNI to the authoritative when 632 attempting encrypted transport. 634 If the recursive resolver needs to send SNI to the authoritative for 635 some reason not found in this document, it is RECOMMENDED that it 636 implements Encrypted Client Hello ([I-D.ietf-tls-esni]) to reduce 637 leakage. 639 4.5.3.4. Authoritative Server Authentication 641 A recursive resolver following this guidance MAY attempt to verify 642 the server's identity by X.509 certificate or DANE. When doing so, 643 the identity would presumably be based on the NS name used for a 644 given query. 646 However, since this probing policy is unilateral and opportunistic, 647 the client connecting under this policy MUST accept any certificate 648 presented by the server. If the client cannot verify the server's 649 identity, it MAY use that information for reporting, logging, or 650 other analysis purposes. But it MUST NOT reject the connection due 651 to the authentication failure, as the result would be falling back to 652 cleartext, which would leak the content of the session to a passive 653 network monitor. 655 4.5.4. Establishing an encrypted transport connection 657 When an encrypted transport connection actually completes (e.g., the 658 TLS handshake completes) at time T1, the resolver sets E-completed[X] 659 to T1 and does the following: 661 If the handshake completed successfully: 663 * update E-session[X] so that it is in state established 665 * set E-status[X] to success 667 * for each query Q in E-queries[X]: 669 - if early data was accepted and Q is early, 671 o set the status of Q to sent 673 - otherwise: 675 o send Q through the session (see Section 4.5.8), and set the 676 status of Q to sent 678 * set E-last-activity[X] to T1 680 4.5.5. Failing to establish an encrypted transport connection 682 If, at time T2 an encrypted transport handshake completes with a 683 failure (e.g. a TLS alert), 685 * set E-session[X] to null 687 * set E-status[X] to fail 689 * set E-completed[X] to T2 691 * for each query Q in E-queries[X]: 693 - if Q is not present in any other *-queries[X] or in 694 Do53-queries[X], add Q to Do53-queries[X] and send query Q to X 695 over Do53. 697 Note that this failure will trigger the recursive resolver to fall 698 back to cleartext queries to the authoritative server at IP address 699 X. It will retry encrypted transport to X once the damping timer has 700 elapsed. 702 4.5.6. Encrypted transport failure 704 Once established, an encrypted transport might fail for a number of 705 reasons (e.g., decryption failure, or improper protocol sequence). 707 If this happens: 709 * set E-session[X] to null 711 * set E-status[X] to fail 713 * for each query Q in E-queries[X]: 715 - if Q is not present in any other *-queries[X] or in 716 Do53-queries[X], add Q to Do53-queries[X] and send query Q to X 717 over Do53. FIXME: should a resumption ticket be used here for 718 this previously successful connection? 720 Note that this failure will trigger the recursive resolver to fall 721 back to cleartext queries to the authoritative server at IP address 722 X. It will retry encrypted transport to X once the damping timer has 723 elapsed. 725 FIXME: are there specific forms of failure that we might handle 726 differently? For example, What if a TCP timeout closes an idle DoT 727 connection? What if a QUIC stream ends up timing out but other 728 streams on the same QUIC connection are going through? Do the 729 described scenarios cover the case when an encrypted transport's port 730 is made unavailable/closed? 732 4.5.7. Handling clean shutdown of encrypted transport connection 734 At time T3, the recursive resolver may find that authoritative server 735 X cleanly closes an existing outstanding connection (most likely due 736 to resource exhaustion, see Section 3.4). 738 When this happens: 740 * set E-session[X] to null 742 * for each query Q in E-queries[X]: 744 - if Q is not present in any other *-queries[X] or in 745 Do53-queries[X], add Q to Do53-queries[X] and send query Q to X 746 over Do53. 748 Note that this premature shutdown will trigger the recursive resolver 749 to fall back to cleartext queries to the authoritative server at IP 750 address X. Any subsequent query to X will retry the encrypted 751 connection promptly. 753 4.5.8. Sending a query over encrypted transport 755 When sending a query to an authoritative server over encrypted 756 transport at time T4, the recursive resolver should take a few 757 reasonable steps to ensure privacy and efficiency. 759 When sending query Q, the recursive resolver should ensure that its 760 state in E-queries[X] is set to sent. 762 The recursive resolver also sets E-last-activity[X] to T4. 764 In addition, the recursive resolver should consider the following 765 guidance: 767 4.5.8.1. Avoid EDNS client subnet 769 To protect the privacy of the client, the recursive resolver SHOULD 770 NOT send EDNS(0) Client Subnet information to the authoritative 771 server ([RFC7871]) unless explicitly authorized to do so by the 772 client. 774 4.5.8.2. Pad to standard policy 776 To increase the anonymity set for each query, the recursive resolver 777 SHOULD use EDNS(0) padding according to policies described in 778 [RFC8467]. 780 4.5.8.3. Send queries in separate channels 782 When multiple queries are multiplexed on a single encrypted transport 783 to a single authoritative server, the recursive resolver MUST offer 784 distinct query ID fields for every outstanding query on a connection, 785 and MUST be capable of receiving responses out of order. 787 To the extent that the encrypted transport can avoid head-of-line 788 blocking (e.g. QUIC can use a separate stream per query) the 789 recursive resolver SHOULD avoid head-of-line blocking. 791 4.5.9. Receiving a response over encrypted transport 793 When a response R for query Q arrives at the recursive resolver over 794 encrypted transport E from authoritative server with IP address X at 795 time T5, if Q is in E-queries[X], the recursive resolver takes the 796 following steps: 798 * Remove R from E-queries[X] 800 * Set E-last-activity[X] to T5 801 * If R is successful: 803 - send R to the requesting client 805 - For each supported encrypted transport N other than E: 807 o If Q is in N-queries[X]: 809 + Remove Q from N-queries[X] 811 - If Q is in Do53-queries[X]: 813 o Remove Q from Do53-queries[X] 815 * Otherwise (R is unsuccessful, e.g., SERVFAIL): 817 - If Q is not in Do53-queries[X] or any other *-queries[X]: 819 o Return SERVFAIL to the requesting client FIXME: What 820 response should be sent to the clients in the case that 821 extended DNS errors are used in an authoritative's response? 823 4.5.10. Resource Exhaustion 825 To keep resources under control, a recursive resolver should 826 proactively manage outstanding encrypted connections. Section 6.5 of 827 [I-D.ietf-dprive-dnsoquic] ("Connection Handling") offers useful 828 guidance for clients managing DoQ connections. Section 3.4 of 829 [RFC7858] offers useful guidance for clients managing DoT 830 connections. 832 Even with sensible connection managment, a recursive resolver doing 833 unilateral probing may find resources unexpectedly scarce, and may 834 need to close some outstanding connections. 836 In such a situation, the recursive resolver SHOULD use a reasonable 837 prioritization scheme to close outstanding connections. 839 One reasonable prioritization scheme would be: 841 * close outstanding established sessions based on E-last-activity[X] 842 (oldest timestamp gets closed first) 844 Note that when resources are limited, a recursive resolver following 845 this guidance may also choose not to initiate new connections for 846 encrypted transport. 848 4.5.11. Maintaining connections 850 Some recursive resolvers looking to amortize connection costs, and to 851 minimize latency MAY choose to synthesize queries to a particular 852 resolver to keep a encrypted transport session active. 854 A recursive resolver that adopts this approach should try to align 855 the synthesized queries with other optimizations. For example, a 856 recursive resolver that "pre-fetches" a particular resource record to 857 keep its cache "hot" can send that query over an established 858 encrypted transport session. 860 5. Signalling for Stronger Defense 862 This draft _does not_ contemplate the specification of any form of 863 coordinated signalling between authoritative servers and recursive 864 resolvers, as such measures would not be unilateral. 866 However, the draft highlights the needs of a signaling mechanism for 867 stronger defense. 869 We highlight the following questions for other specifications to 870 solve: 872 * What does the signal need to contain? 874 - type of transport? (DoQ? DoT? DoH?) 876 - error reporting if secure, authenticated connection fails (how 877 to report? similar to TLSRPT?) 879 - whether to hard-fail if encrypted communication isn't available 881 - cryptographic authentication of authoritative server (e.g. 882 pubkeys) vs. names vs. domain? 884 * How should the signal be presented? 886 - SVCB RR or "surprising" DS RR 888 * How should the signal be scoped? 890 - per-nameserver (by NS), per-nameserver (by IP address, via in- 891 addr.arpa), or per-domain? 893 5.1. Combining Signals with Opportunistic Probing 895 FIXME: How do the signals get combined with the above opportunistic 896 probing policy? Can we specify that without needing to specify the 897 signalling mechanism itself? 899 6. IANA Considerations 901 IANA does not need to do anything for implementers to adopt the 902 guidance found in this draft. 904 7. Privacy Considerations 906 7.1. Server Name Indication 908 A recursive resolver querying an authoritative server over DoT or DoQ 909 that sends Server Name Indication (SNI) in the clear in the 910 cryptographic handshake leaks information about the intended query to 911 a passive network observer. 913 In particular, if two different zones refer to the same nameserver IP 914 addresses via differently-named NS records, a passive network 915 observer can distinguish queries to one zone from the queries to the 916 other. 918 Omitting SNI entirely, or using ECH to hide the intended SNI, avoids 919 this additional leakage. However, a series of queries that leak this 920 information is still an improvement over the all-cleartext status quo 921 at the time of this document. 923 8. Security Considerations 925 The guidance in this draft provides defense against passive network 926 monitors for most queries. It does not defend against active 927 attackers. It can also leak some queries and their responses due to 928 "happy eyeballs" optimizations when the resolver's cache is cold. 930 Implementation of the guidance in this draft should increase 931 deployment of opportunistic encrypted DNS transport between recursive 932 resolvers and authoritative servers at little operational risk. 934 However, implementers should not rely on the guidance in this draft 935 for robust defense against active attackers, but should treat it as a 936 stepping stone en route to stronger defense. 938 In particular, a recursive resolver following this guidance can 939 easily be forced by an active attacker to fall back to cleartext DNS 940 queries. Or, an active attacker could position itself as a machine- 941 in-the-middle, which the recursive resolver would not defend against 942 or detect due to lack of server authentication. Defending against 943 these attacks without risking additional unexpected protocol failures 944 would require signalling and coordination that are out of scope for 945 this draft. 947 This guidance is only one part of operating a privacy-preserving DNS 948 ecosystem. A privacy-preserving recursive resolver should adopt 949 other practices as well, such as QNAME minimization, local root zone, 950 etc, to reduce the overall leakage of query information that could 951 infringe on the client's privacy. 953 9. Acknowledgements 955 Many people contributed to the development of this draft beyond the 956 authors, including Brian Dickson, Christian Huitema, Eric Nygren, Jim 957 Reid, Kris Shrishak, Paul Hoffman, Ralf Weber, Robert Evans, and the 958 DPRIVE working group. 960 10. References 962 10.1. Normative References 964 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 965 Requirement Levels", BCP 14, RFC 2119, 966 DOI 10.17487/RFC2119, March 1997, 967 . 969 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 970 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 971 May 2017, . 973 10.2. Informative References 975 [RFC1035] Mockapetris, P., "Domain names - implementation and 976 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 977 November 1987, . 979 [I-D.ietf-dprive-dnsoquic] 980 Huitema, C., Dickinson, S., and A. Mankin, "DNS over 981 Dedicated QUIC Connections", Work in Progress, Internet- 982 Draft, draft-ietf-dprive-dnsoquic-10, 28 February 2022, 983 . 986 [I-D.ietf-tls-esni] 987 Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 988 Encrypted Client Hello", Work in Progress, Internet-Draft, 989 draft-ietf-tls-esni-14, 13 February 2022, 990 . 993 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 994 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 995 December 2014, . 997 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 998 and P. Hoffman, "Specification for DNS over Transport 999 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1000 2016, . 1002 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 1003 Kumari, "Client Subnet in DNS Queries", RFC 7871, 1004 DOI 10.17487/RFC7871, May 2016, 1005 . 1007 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1008 Better Connectivity Using Concurrency", RFC 8305, 1009 DOI 10.17487/RFC8305, December 2017, 1010 . 1012 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 1013 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 1014 October 2018, . 1016 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1017 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1018 . 1020 Appendix A. Document Considerations 1022 [ RFC Editor: please remove this section before publication ] 1024 This document is currently edited as markdown. Minor editorial 1025 changes can be suggested via merge requests at 1026 https://gitlab.com/dkg/dprive-unilateral-probing or by e-mail to the 1027 editor. Please direct all significant commentary to the public IETF 1028 DPRIVE mailing list: dprive@ietf.org 1030 The authors' latest draft can be read online in html 1031 (https://dkg.gitlab.io/dprive-unilateral-probing/) or pdf 1032 (https://dkg.gitlab.io/dprive-unilateral-probing/unilateral- 1033 probing.pdf) or text (https://dkg.gitlab.io/dprive-unilateral- 1034 probing/unilateral-probing.txt) formats. 1036 A.1. Document History 1038 A.1.1. Substantive changes from -01 to -02 1040 * Clarify that deployment to a pool does not need to be strictly 1041 simultaneous 1043 * Explain why authoritatives need to serve the same records 1044 regardless of SNI 1046 * Defer to external, protocol-specific references for resource 1047 management 1049 * Clarify that probed connections must not fail due to 1050 authentication failure 1052 A.1.2. Substantive changes from -00 to -01 1054 * Fallback to cleartext when encrypted transport fails. 1056 * Reduce default timeout to 4s 1058 * Clarify SNI guidance: OK for selecting server credentials, not OK 1059 for changing answers 1061 * Document ALPN and port numbers 1063 * Justify sorting recursive resolver state by authoritative IP 1064 address 1066 Authors' Addresses 1068 Daniel Kahn Gillmor 1069 American Civil Liberties Union 1070 125 Broad St. 1071 New York, NY, 10004 1072 United States of America 1073 Email: dkg@fifthhorseman.net 1075 Joey Salazar 1076 Alajuela 1077 20201 1078 Costa Rica 1079 Email: joeygsal@gmail.com