idnits 2.17.1 draft-dkgjsal-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 (18 November 2021) is 890 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'X' is mentioned on line 709, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-06 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-13 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: 22 May 2022 A19 6 18 November 2021 8 Unilateral Opportunistic Deployment of Encrypted Recursive-to- 9 Authoritative DNS 10 draft-dkgjsal-dprive-unilateral-probing-00 12 Abstract 14 This draft sets out steps that DNS servers (recursive resolvers and 15 authoritative servers) can take unilaterally (without any 16 coordination with other peers) to defend DNS query privacy against a 17 passive network monitor. The steps in this draft can be defeated by 18 an active attacker, but should be simpler and less risky to deploy 19 than more powerful defenses. The draft also introduces (but does not 20 try to specify) the semantics of signalling that would permit defense 21 against an active attacker. 23 The goal of this draft is to simplify and speed deployment of 24 opportunistic encrypted transport in the recursive-to-authoritative 25 hop of the DNS ecosystem. With wider easy deployment of the 26 underlying transport on an opportunistic basis, we hope to facilitate 27 the future specification of stronger cryptographic protections 28 against more powerful attacks. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 22 May 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Priorities . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Minimizing Negative Impacts . . . . . . . . . . . . . . . 4 68 2.2. Protocol Choices . . . . . . . . . . . . . . . . . . . . 4 69 3. Guidance for Authoritative Servers . . . . . . . . . . . . . 4 70 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 5 72 4. Guidance for recursive resolvers . . . . . . . . . . . . . . 6 73 4.1. Overall recursive resolver Settings . . . . . . . . . . . 6 74 4.2. Recursive Resolver Requirements . . . . . . . . . . . . . 7 75 4.3. Authoritative Server Encrypted Transport Connection 76 State . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 4.4. Probing Policy . . . . . . . . . . . . . . . . . . . . . 9 78 4.4.1. Sending a query over Do53 . . . . . . . . . . . . . . 9 79 4.4.2. Receiving a response over Do53 . . . . . . . . . . . 10 80 4.4.3. Initiating a connection over encrypted transport . . 10 81 4.4.4. Establishing an encrypted transport connection . . . 13 82 4.4.5. Failing to establish an encrypted transport 83 connection . . . . . . . . . . . . . . . . . . . . . 13 84 4.4.6. Encrypted transport failure . . . . . . . . . . . . . 13 85 4.4.7. Handling clean shutdown of encrypted transport 86 connection . . . . . . . . . . . . . . . . . . . . . 14 87 4.4.8. Sending a query over encrypted transport . . . . . . 14 88 4.4.9. Receiving a response over encrypted transport . . . . 15 89 4.4.10. Resource Exhaustion . . . . . . . . . . . . . . . . . 16 90 4.4.11. Maintaining connections . . . . . . . . . . . . . . . 16 91 5. Signalling for Stronger Defense . . . . . . . . . . . . . . . 17 92 5.1. Combining Signals with Opportunistic Probing . . . . . . 17 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 98 9.2. Informative References . . . . . . . . . . . . . . . . . 18 99 Appendix A. Document Considerations . . . . . . . . . . . . . . 19 100 A.1. Document History . . . . . . . . . . . . . . . . . . . . 20 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 103 1. Introduction 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 ([RFC2119] and [RFC8174]) when, and only when, they appear in all 111 capitals, as shown here. 113 1.2. Terminology 115 * "unilateral" means capable of opportunistic probing deployment 116 without external coordination with any of the other parties 118 * Do53 refers to traditional cleartext DNS over port 53 ([RFC1035]) 120 * DoQ refers to DNS-over-QUIC ([I-D.ietf-dprive-dnsoquic]) 122 * DoT refers to DNS-over-TLS ([RFC7858]) 124 * DoH refers to DNS-over-HTTPS ([RFC8484]) 126 * Encrypted transports refers to DoQ, DoT, and DoH collectively 128 2. Priorities 130 This document aims to provide guidance to implementers who want to 131 simply enable protection against passive network observers. 133 In particular, it focuses on mechanisms that can be adopted 134 unilaterally by recursive resolvers and authoritative servers, 135 without any explicit coordination with the other parties. This 136 guidance provides opportunistic security (see [RFC7435]) -- 137 encrypting things that would otherwise be in the clear, without 138 interfering with or weakening stronger forms of security. 140 2.1. Minimizing Negative Impacts 142 It also aims to minimize potentially negative impacts caused by the 143 probing of encrypted transports -- for the systems that adopt these 144 guidelines, for the parties that they communicate with in the "second 145 hump" of the DNS camel, and for uninvolved third parties. The 146 negative impacts that we specifically try to minimize are: 148 * excessive bandwidth use 150 * excessive computational resources (CPU and memory in particular) 152 * amplification attacks (where DNS resolution infrastructure is 153 wielded as part of a DoS attack) 155 2.2. Protocol Choices 157 While this document focuses specifically on strategies used by DNS 158 servers, it does not go into detail on the specific protocols used, 159 as those protocols --- in particular, DoT and DoQ --- are described 160 in other documents. 162 This document does not pursue the use of DoH in this context, because 163 a DoH client needs to know the path part of a DoH endpoint URL, and 164 there are currently no mechanisms for a DNS resolver to predict the 165 path on its own, in an opportunistic or unilateral fashion, without 166 incurring in excessive use of resources. For instance, a recursive 167 resolver in theory could guess the full path to a queried IP address 168 by trying all the URL paths that the client has in records and see if 169 one of those works, but even though it can be expected that this 170 would work 99% of the time with fewer than 100 probes, this technique 171 would likely incur in excessive resource consumption potentially 172 leading to vulnerabilities and amplification attacks. The authors of 173 this draft particularly welcome ideas and contributions from the 174 community that lead to a suitable mechanism for unilaterally probing 175 for DoH-capable authoritative servers, for later consideration in 176 this or other drafts. 178 3. Guidance for Authoritative Servers 180 An authoritative server SHOULD implement and deploy DNS-over-TLS 181 (DoT) on TCP port 853. 183 An authoritative server MAY implement and deploy DNS-over-QUIC (DoQ) 184 on UDP port 853. 186 3.1. Authentication 188 For unilateral deployment, an authoritative server does not need to 189 offer any particular form of authentication. 191 The simplest deployment would simply provide a self-issued, 192 regularly-updated X.509 certificate. This mechanism is supported by 193 many TLS and QUIC clients, and will be acceptable for any 194 opportunistic connection. 196 Possible alternate forms of server authentication include: 198 * an X.509 Certificate issued by a widely-known certification 199 authority associated with the common NS names used for this 200 authoritative server 202 * DANE authentication (potentially including the TLS handshake) 204 An authoritative DNS server that wants to handle unilateral queries 205 MUST NOT rely on SNI to multiplex distinct authoritative DNS services 206 on a single IP address. 208 3.2. Resource Exhaustion 210 A well-behaved recursive resolver may keep an encrypted connection 211 open to an authoritative server, to amortize the costs of connection 212 setup for both parties. 214 However, some authoritative servers may have insufficient resources 215 available to keep many connections open concurrently. 217 An authoritative server facing resource exhaustion SHOULD cleanly 218 close open connections from recursive resolvers based on the 219 authoritative's preferred prioritization. 221 A reasonable prioritization scheme would be to close connections in 222 this order, until resources are back in control: 224 * connections with no outstanding queries, ordered by idle time 225 (longest idle time gets closed first) 227 * connections with outstanding queries, ordered by age of 228 outstanding query (oldest outstanding query gets closed first) 230 4. Guidance for recursive resolvers 232 This section outlines a probing policy suitable for unilateral 233 adoption by any recursive resolver. Following this policy should not 234 result in failed resolutions or significant delay. 236 4.1. Overall recursive resolver Settings 238 A recursive resolver implementing this draft must set system-wide 239 values for some default parameters. These parameters may be set 240 independently for each supported encrypted transport, though a simple 241 implementation may keep the parameters constant across encrypted 242 transports. 244 +=============+===================================+===========+ 245 | Name | Description | Suggested | 246 | | | Default | 247 +=============+===================================+===========+ 248 | persistence | How long should the recursive | 3 days | 249 | | resolver remember successful | (259200 | 250 | | encrypted transport connections? | seconds) | 251 +-------------+-----------------------------------+-----------+ 252 | damping | How long should the recursive | 1 day | 253 | | resolver remember unsuccessful | (86400 | 254 | | encrypted transport connections? | seconds) | 255 +-------------+-----------------------------------+-----------+ 256 | timeout | How long should the recursive | 30 | 257 | | resolver wait for an initiated | seconds | 258 | | encrypted connection to complete? | | 259 +-------------+-----------------------------------+-----------+ 261 Table 1: recursive resolver system parameters per encrypted 262 transport 264 This document uses the notation E-foo to refer to the foo parameter 265 for the encrypted transport E. 267 For example DoT-persistence would indicate the length of time that 268 the recursive resolver will remember that an authoritative server had 269 a successful connection over DoT. 271 This document also assumes that the resolver maintains a list of 272 outstanding cleartext queries destined for the authoritative 273 resolver's IP address X. This list is referred to as 274 Do53-queries[X]. This document does not attempt to describe the 275 specific operation of sending and receiving cleartext DNS queries 276 (Do53) for a recursive resolver. Instead it describes a "bolt-on" 277 mechanism that extends the recursive resolver's operation on a few 278 simple hooks into the recursive resolver's existing handling of Do53. 280 Implementers or deployers of DNS recursive resolvers that follow the 281 strategies in this document are encouraged to report their preferred 282 values of these parameters. 284 4.2. Recursive Resolver Requirements 286 To follow this guidance, a recursive resolver MUST implement at least 287 one of either DoT or DoQ in its capacity as a client of authoritative 288 nameservers. 290 A recursive resolver SHOULD implement the client side of DNS-over-TLS 291 (DoT). A recursive resolver MAY implement the client side of DNS- 292 over-QUIC (DoQ). 294 While this document focuses on the recursive-to-authoritative hop, a 295 recursive resolver implementing these strategies SHOULD also accept 296 queries from its clients over some encrypted transport (current 297 common transports are DoH or DoT). 299 4.3. Authoritative Server Encrypted Transport Connection State 301 The recursive resolver SHOULD keep a record of the state for each 302 authoritative server it contacts, indexed by the IP address of the 303 authoritative server and the encrypted transports supported by the 304 recursive resolver. 306 Each record should contain the following fields for each supported 307 encrypted transport, each of which would initially be null: 309 +===============+==========================================+========+ 310 | Name | Description | Retain | 311 | | | Across | 312 | | | Reset | 313 +===============+==========================================+========+ 314 | session | The associated state of any | N | 315 | | existing, established session (the | | 316 | | structure of this value is dependent | | 317 | | on the encrypted transport | | 318 | | implementation). If session is not | | 319 | | null, it may be in one of two | | 320 | | states: pending or established | | 321 +---------------+------------------------------------------+--------+ 322 | initiated | Timestamp of most recent connection | Y | 323 | | attempt | | 324 +---------------+------------------------------------------+--------+ 325 | completed | Timestamp of most recent completed | Y | 326 | | handshake | | 327 +---------------+------------------------------------------+--------+ 328 | status | Enumerated value of success or fail | Y | 329 | | or timeout, associated with the | | 330 | | completed handshake | | 331 +---------------+------------------------------------------+--------+ 332 | resumptions | A stack of resumption tickets (and | Y | 333 | | associated parameters) that could be | | 334 | | used to resume a prior successful | | 335 | | connection | | 336 +---------------+------------------------------------------+--------+ 337 | queries | A queue of queries intended for this | N | 338 | | authoritative server, each of which | | 339 | | has additional status early, unsent, | | 340 | | or sent | | 341 +---------------+------------------------------------------+--------+ 342 | last-activity | A timestamp of the most recent | N | 343 | | activity on the connection | | 344 +---------------+------------------------------------------+--------+ 346 Table 2: recursive resolver state per authoritative IP, per encrypted 347 transport 349 Note that the session fields in aggregate constitute a pool of open 350 connections to different servers. 352 With the exception of the session, queries, and last-activity fields, 353 this cache information should be kept across restart of the server 354 unless explicitly cleared by administrative action. 356 This document uses the notation E-foo[X] to indicate the value of 357 field foo for encrypted transport E to IP address X. 359 For example, DoT-initiated[192.0.2.4] represents the timestamp when 360 the most recent DoT connection packet was sent to IP address 361 192.0.2.4. 363 4.4. Probing Policy 365 When a recursive resolver discovers the need for an authoritative 366 lookup to an authoritative DNS server using IP address X, it 367 retrieves the records associated with X from its cache. 369 The following sections presume that the time of the discovery of the 370 need for lookup is time T0. 372 If any of the records discussed here are absent, they are treated as 373 null. 375 The recursive resolver must know to decide whether to initially send 376 a query over Do53, or over any of the supported encrypted transports 377 (DoT or DoQ). 379 Note that a resolver might initiate this query via any or all of the 380 known transports. When multiple queries are sent, the initial 381 packets for each connection can be sent concurrently, similar to 382 "Happy Eyeballs" ([RFC8305]). However, unlike Happy Eyeballs, when 383 one transport succeeds, the other connections do not need to be 384 terminated, but can instead be continued to establish whether the IP 385 address X is capable of corresponding on the relevant transport. 387 4.4.1. Sending a query over Do53 389 For any of the supported encrypted transports E, if either of the 390 following holds true, the resolver SHOULD NOT send a query to X over 391 Do53: 393 * E-session[X] is in the established state, or 395 * E-status[X] is success, and (T - E-completed[X]) < persistence 397 Otherwise, if there is no outstanding session for any encrypted 398 transport, and the last successful encrypted transport connection was 399 long ago, the resolver sends a query to X over Do53. When it does 400 so, it inserts a handle for the query in Do53-queries[X]. 402 4.4.2. Receiving a response over Do53 404 When a successful response R is received in cleartext from 405 authoritative server X for a query Q that was sent over Do53, the 406 recursive resolver should: 408 * If Q is in Do53-queries[X]: 410 - Return R to the requesting client 412 * Remove Q from Do53-queries[X] 414 * For each supported encrypted transport E: 416 - If Q is in E-queries[X]: 418 o Remove Q from E-queries[X] 420 But if R is unsuccessful (e.g. SERVFAIL): 422 * if Q is not in any of *-queries[X]: 424 - Return SERVFAIL to the client 426 4.4.3. Initiating a connection over encrypted transport 428 If any E-session[X] is in the established, the recursive resolver 429 SHOULD NOT initiate a new connection to X over any other transport, 430 but should instead send a query through the existing session (see 431 Section 4.4.8). FIXME: What if there's a preferred transport, but 432 the established session does not correspond to that preferred 433 transport? 435 Otherwise, the timer should examine and possibly refresh its state 436 for encrypted transport E to authoritative IP address X: 438 * if E-session[X] is in state pending, and 440 * T - E-initiated[X] > E-timeout, then 442 - set E-session[X] to null and 444 - set E-status[X] to timeout 446 When resources are available to attempt a new encrypted transport, 447 the resolver should only initiate a new connection to X over E as 448 long as one of the following holds true: 450 * E-status[X] is success, or 452 * E-status[X] is fail or timeout and (T - E-completed[X]) > damping, 453 or 455 * E-status[X] is null and E-initiated[X] is null 457 When initiating a session to X over encrypted transport E, if 458 E-resumptions[X] is not empty, one ticket should be popped off the 459 stack and used to try to resume a previous session. Otherwise, the 460 initial Client Hello handshake should not try to resume any session. 462 When initiating a connection, the resolver should take the following 463 steps: 465 * set E-initiated[X] to T0 467 * store a handle for the new session (which should have pending 468 state) in E-session[X] 470 * insert a handle for the query that prompted this connection in 471 E-queries[X], with status unsent or early, as appropriate (see 472 below). 474 4.4.3.1. Early Data 476 Modern encrypted transports like TLS 1.3 offer the chance to store 477 "early data" from the client into the initial Client Hello in some 478 contexts. A resolver that initiates a connection over a encrypted 479 transport according to this guidance in a context where early data is 480 possible SHOULD send the DNS query that prompted the connection in 481 the early data, according to the sending guidance in Section 4.4.8. 483 If it does so, the status of Q in E-queries[X] should be set to early 484 instead of unsent. 486 4.4.3.2. Resumption Tickets 488 When initiating a new connection (whether by resuming an old session 489 or not), the recursive resolver SHOULD request a session resumption 490 ticket from the authoritative server. If the authoritative server 491 supplies a resumption ticket, the recursive resolver pushes it into 492 the stack at E-resumptions[X]. 494 4.4.3.3. Server Name Indication 496 For modern encrypted transports like TLS 1.3, most client 497 implementations expect to send a Server Name Indication (SNI) in the 498 Client Hello. 500 There are two complications with selecting or sending SNI in this 501 unilateral probing: 503 * Some authoritative servers are known by more than one name; 504 selecting a single name to use for a given connection may be 505 difficult or impossible. 507 * In most configurations, the contents of the SNI field is exposed 508 on the wire to a passive adversary. This potentially reveals 509 additional information about which query is being made, based on 510 the NS of the query itself. 512 To avoid additional leakage and complexity, a recursive resolver 513 using only this guidance SHOULD NOT send any SNI to the authoritative 514 when attempting encrypted transport. 516 Alternately, if the recursive resolver implements Encrypted Client 517 Hello ([I-D.ietf-tls-esni] and the appropriate records are available 518 for the NS in question, the recursive resolver MAY send an SNI under 519 encryption. 521 4.4.3.4. Authoritative Server Authentication 523 A recursive resolver following this guidance MAY attempt to verify 524 the server's identity by X.509 certificate or DANE. When doing so, 525 the identity would presumably be based on the NS name used for a 526 given query. 528 However, since this probing policy is unilateral and opportunistic, 529 the client SHOULD NOT consider it a failure if an encrypted transport 530 handshake that does not authenticate to any particular expected name. 532 To avoid the complexity of authoritative servers with multiple 533 simultaneous names, or multiple names over time, this draft does not 534 attempt to describe what name a recursive resolver should use when 535 validating an authoritative server, or what the recursive resolver 536 should do with an authentication success. 538 4.4.4. Establishing an encrypted transport connection 540 When an encrypted transport connection actually completes (e.g., the 541 TLS handshake completes) at time T1, the resolver sets E-completed[X] 542 to T1 and does the following: 544 If the handshake completed successfully: 546 * update E-session[X] so that it is in state established 548 * set E-status[X] to success 550 * for each query Q in E-queries[X]: 552 - if early data was accepted and Q is early, 554 o set the status of Q to sent 556 - otherwise: 558 o send Q through the session (see Section 4.4.8), and set the 559 status of Q to sent 561 * set E-last-activity[X] to T1 563 4.4.5. Failing to establish an encrypted transport connection 565 If, at time T2 an encrypted transport handshake completes with a 566 failure (e.g. a TLS alert), 568 * set E-session[X] to null 570 * set E-status[X] to fail 572 * set E-completed[X] to T2 574 * for each query Q in E-queries[X]: 576 - if Q is not present in any other *-queries[X] or in 577 Do53-queries[X], report SERVFAIL to the requesting client. 578 FIXME: should there be retries in this scenario? Or should the 579 recursive then try a different encrypted transport? 581 4.4.6. Encrypted transport failure 583 Once established, an encrypted transport might fail for a number of 584 reasons (e.g., decryption failure, or improper protocol sequence). 586 If this happens: 588 * set E-session[X] to null 590 * set E-status[X] to fail 592 * for each query Q in E-queries[X]: 594 - if Q is not present in any other *-queries[X] or in 595 Do53-queries[X], report SERVFAIL to the requesting client. 596 FIXME: should a resumption ticket be used here for this 597 previously successful connection? Or a retry? 599 FIXME: are there specific forms of failure that we might handle 600 differently? For example, What if a TCP timeout closes an idle DoT 601 connection? What if a QUIC stream ends up timing out but other 602 streams on the same QUIC connection are going through? Do the 603 described scenarios cover the case when an encrypted transport's port 604 is made unavailable/closed? 606 4.4.7. Handling clean shutdown of encrypted transport connection 608 At time T3, the recursive resolver may find that authoritative server 609 X cleanly closes an existing outstanding connection (most likely due 610 to resource exhaustion, see Section 3.2). 612 When this happens: 614 * set E-session[X] to null 616 * for each query Q in E-queries[X]: 618 - if Q is not present in any other *-queries[X] or in 619 Do53-queries[X], report SERVFAIL to the requesting client. 621 4.4.8. Sending a query over encrypted transport 623 When sending a query to an authoritative server over encrypted 624 transport at time T4, the recursive resolver should take a few 625 reasonable steps to ensure privacy and efficiency. 627 When sending query Q, the recursive resolver should ensure that its 628 state in E-queries[X] is set to sent. 630 The recursive resolver also sets E-last-activity[X] to T4. 632 In addition, the recursive resolver should consider the following 633 guidance: 635 4.4.8.1. Avoid EDNS client subnet 637 To protect the privacy of the client, the recursive resolver SHOULD 638 NOT send EDNS(0) Client Subnet information to the authoritative 639 server ([RFC7871]) unless explicitly authorized to do so by the 640 client. 642 4.4.8.2. Pad to standard policy 644 To increase the anonymity set for each query, the recursive resolver 645 SHOULD use EDNS(0) padding according to policies described in 646 [RFC8467]. 648 4.4.8.3. Send queries in separate channels 650 When multiple queries are multiplexed on a single encrypted transport 651 to a single authoritative server, the recursive resolver MUST offer 652 distinct query ID fields for every outstanding query on a connection, 653 and MUST be capable of receiving responses out of order. 655 To the extent that the encrypted transport can avoid head-of-line 656 blocking (e.g. QUIC can use a separate stream per query) the 657 recursive resolver SHOULD avoid head-of-line blocking. 659 4.4.9. Receiving a response over encrypted transport 661 When a response R for query Q arrives at the recursive resolver over 662 encrypted transport E from authoritative server with IP address X at 663 time T5, if Q is in E-queries[X], the recursive resolver takes the 664 following steps: 666 * Remove R from E-queries[X] 668 * Set E-last-activity[X] to T5 670 * If R is successful: 672 - send R to the requesting client 674 - For each supported encrypted transport N other than E: 676 o If Q is in N-queries[X]: 678 + Remove Q from N-queries[X] 680 - If Q is in Do53-queries[X]: 682 o Remove Q from Do53-queries[X] 684 * Otherwise (R is unsuccessful, e.g., SERVFAIL): 686 - If Q is not in Do53-queries[X] or any other *-queries[X]: 688 o Return SERVFAIL to the requesting client FIXME: What 689 response should be sent to the clients in the case that 690 extended DNS errors are used in an authoritative's response? 692 4.4.10. Resource Exhaustion 694 Over time, a recursive resolver following this policy may find that 695 it is limited in resources, and may prefer to close some outstanding 696 connections. 698 This could be done by checking available/consumed resources on a 699 fixed schedule, by having a policy of only keeping a fixed number of 700 connections open, by checking resources when activity occurs, or by 701 some other cadence. 703 When existing connections should be closed, the recursive resolver 704 should use a reasonable prioritization scheme to close outstanding 705 connections. 707 One reasonable prioritization scheme would be: 709 * close outstanding established sessions based on E-last-activity[X] 710 (oldest timestamp gets closed first) 712 Note that when resources are limited, a recursive resolver following 713 this guidance may also choose not to initiate new connections for 714 encrypted transport. 716 4.4.11. Maintaining connections 718 Some recursive resolvers looking to amortize connection costs, and to 719 minimize latency MAY choose to synthesize queries to a particular 720 resolver to keep a encrypted transport session active. 722 A recursive resolver that adopts this approach should try to align 723 the synthesized queries with other optimizations. For example, a 724 recursive resolver that "pre-fetches" a particular resource record to 725 keep its cache "hot" can send that query over an established 726 encrypted transport session. 728 5. Signalling for Stronger Defense 730 This draft _does not_ contemplate the specification of any form of 731 coordinated signalling between authoritative servers and recursive 732 resolvers, as such measures would not be unilateral. 734 However, the draft highlights the needs of a signaling mechanism for 735 stronger defense. 737 We highlight the following questions for other specifications to 738 solve: 740 * What does the signal need to contain? 742 - type of transport? (DoQ? DoT? DoH?) 744 - error reporting if secure, authenticated connection fails (how 745 to report? similar to TLSRPT?) 747 - whether to hard-fail if encrypted communication isn't available 749 - cryptographic authentication of authoritative server (e.g. 750 pubkeys) vs. names vs. domain? 752 * How should the signal be presented? 754 - SVCB RR or "surprising" DS RR 756 * How should the signal be scoped? 758 - per-nameserver (by NS), per-nameserver (by IP address, via in- 759 addr.arpa), or per-domain? 761 5.1. Combining Signals with Opportunistic Probing 763 FIXME: How do the signals get combined with the above opportunistic 764 probing policy? Can we specify that without needing to specify the 765 signalling mechanism itself? 767 6. IANA Considerations 769 IANA does not need to do anything for implementers to adopt the 770 guidance found in this draft. 772 7. Security Considerations 774 The guidance in this draft provides defense against passive network 775 monitors for most queries. It does not defend against active 776 attackers. It can also leak some queries and their responses due to 777 "happy eyeballs" optimizations when the resolver's cache is cold. 779 Implementation of the guidance in this draft should increase 780 deployment of opportunistic encrypted DNS transport between recursive 781 resolvers and authoritative servers at little operational risk. 783 However, implementers should not rely on the guidance in this draft 784 for robust defense against active attackers, but should treat it as a 785 stepping stone en route to stronger defense. 787 This guidance is only one part of operating a privacy-preserving DNS 788 ecosystem. A privacy-preserving recursive resolver should adopt 789 other practices as well, such as QNAME minimization, local root zone, 790 etc, to reduce the overall leakage of query information that could 791 infringe on the client's privacy. 793 8. Acknowledgements 795 9. References 797 9.1. Normative References 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, 801 DOI 10.17487/RFC2119, March 1997, 802 . 804 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 805 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 806 May 2017, . 808 9.2. Informative References 810 [RFC1035] Mockapetris, P., "Domain names - implementation and 811 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 812 November 1987, . 814 [I-D.ietf-dprive-dnsoquic] 815 Huitema, C., Dickinson, S., and A. Mankin, "DNS over 816 Dedicated QUIC Connections", Work in Progress, Internet- 817 Draft, draft-ietf-dprive-dnsoquic-06, 20 October 2021, 818 . 821 [I-D.ietf-tls-esni] 822 Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 823 Encrypted Client Hello", Work in Progress, Internet-Draft, 824 draft-ietf-tls-esni-13, 12 August 2021, 825 . 828 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 829 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 830 December 2014, . 832 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 833 and P. Hoffman, "Specification for DNS over Transport 834 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 835 2016, . 837 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 838 Kumari, "Client Subnet in DNS Queries", RFC 7871, 839 DOI 10.17487/RFC7871, May 2016, 840 . 842 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 843 Better Connectivity Using Concurrency", RFC 8305, 844 DOI 10.17487/RFC8305, December 2017, 845 . 847 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 848 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 849 October 2018, . 851 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 852 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 853 . 855 Appendix A. Document Considerations 857 [ RFC Editor: please remove this section before publication ] 859 This document is currently edited as markdown. Minor editorial 860 changes can be suggested via merge requests at 861 https://gitlab.com/dkg/dprive-unilateral-probing or by e-mail to the 862 editor. Please direct all significant commentary to the public IETF 863 DPRIVE mailing list: dprive@ietf.org 864 The authors' latest draft can be read online in html 865 (https://dkg.gitlab.io/dprive-unilateral-probing/) or pdf 866 (https://dkg.gitlab.io/dprive-unilateral-probing/unilateral- 867 probing.pdf) or text (https://dkg.gitlab.io/dprive-unilateral- 868 probing/unilateral-probing.txt) formats. 870 A.1. Document History 872 Authors' Addresses 874 Daniel Kahn Gillmor 875 American Civil Liberties Union 876 125 Broad St. 877 New York, NY, 10004 878 United States of America 880 Email: dkg@fifthhorseman.net 882 Joey Salazar 883 ARTICLE 19 884 108-114 Golden Lane 885 London 886 EC1Y 0TL 887 United Kingdom 889 Email: joeygsal@gmail.com