idnits 2.17.1 draft-huitema-dprive-dnsoquic-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 05, 2020) is 1507 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-terminology-ter-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-dnsop-terminology-ter' == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-27 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 == Outdated reference: A later version (-02) exists of draft-ietf-dprive-phase2-requirements-00 == Outdated reference: A later version (-09) exists of draft-ietf-dprive-rfc7626-bis-04 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-xfr-over-tls-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-27 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-26 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Private Octopus Inc. 4 Intended status: Standards Track A. Mankin 5 Expires: September 6, 2020 Salesforce 6 S. Dickinson 7 Sinodun IT 8 March 05, 2020 10 Specification of DNS over Dedicated QUIC Connections 11 draft-huitema-dprive-dnsoquic-00 13 Abstract 15 This document describes the use of QUIC to provide transport privacy 16 for DNS. The encryption provided by QUIC has similar properties to 17 that provided by TLS, while QUIC transport eliminates the head-of- 18 line blocking issues inherent with TCP and provides more efficient 19 error corrections than UDP. DNS over QUIC (DoQ) has privacy 20 properties similar to DNS over TLS (DoT) specified in RFC7858, and 21 performance characteristics similar to classic DNS over UDP. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 6, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Scope is Limited to the Stub to Resolver Scenario . . . . 4 61 3.2. Provide DNS Privacy . . . . . . . . . . . . . . . . . . . 5 62 3.3. Design for Minimum Latency . . . . . . . . . . . . . . . 5 63 3.4. No Specific Middlebox Bypass Mechanism . . . . . . . . . 6 64 4. Specifications . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Connection Establishment . . . . . . . . . . . . . . . . 6 66 4.1.1. Draft Version Identification . . . . . . . . . . . . 6 67 4.1.2. Port Selection . . . . . . . . . . . . . . . . . . . 7 68 4.2. Stream Mapping and Usage . . . . . . . . . . . . . . . . 7 69 4.2.1. Server Initiated Transactions . . . . . . . . . . . . 8 70 4.2.2. Stream Reset . . . . . . . . . . . . . . . . . . . . 8 71 4.3. Connection Management . . . . . . . . . . . . . . . . . . 8 72 4.4. Connection Resume and 0-RTT . . . . . . . . . . . . . . . 9 73 5. Implementation Requirements . . . . . . . . . . . . . . . . . 9 74 5.1. Authentication . . . . . . . . . . . . . . . . . . . . . 9 75 5.2. Fall Back to Other Protocols on Connection Failure . . . 10 76 5.3. Address Validation . . . . . . . . . . . . . . . . . . . 10 77 5.4. Response Sizes . . . . . . . . . . . . . . . . . . . . . 10 78 5.5. DNS Message IDs . . . . . . . . . . . . . . . . . . . . . 11 79 5.6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 5.7. Connection Handling . . . . . . . . . . . . . . . . . . . 11 81 5.7.1. Connection Reuse . . . . . . . . . . . . . . . . . . 11 82 5.7.2. Connection Close . . . . . . . . . . . . . . . . . . 12 83 5.7.3. Idle Timeouts . . . . . . . . . . . . . . . . . . . . 12 84 5.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 13 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 87 7.1. Privacy Issues With Zero RTT data . . . . . . . . . . . . 13 88 7.2. Privacy Issues With Session Resume . . . . . . . . . . . 14 89 7.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 14 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 91 8.1. Registration of DoQ Identification String . . . . . . . . 15 92 8.2. Reservation of Dedicated Port . . . . . . . . . . . . . . 15 93 8.2.1. Port number 784 for experimentations . . . . . . . . 15 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 97 10.2. Informative References . . . . . . . . . . . . . . . . . 17 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 Domain Name System (DNS) concepts are specified in [RFC1034]. This 103 document presents a mapping of the DNS protocol [RFC1035] over QUIC 104 transport [I-D.ietf-quic-transport] [I-D.ietf-quic-tls]. DNS over 105 QUIC is refered here as DoQ, in line with the terminology presented 106 in [I-D.ietf-dnsop-terminology-ter]. The goals of the DoQ mapping 107 are: 109 1. Provide the same DNS privacy protection as DNS over TLS (DoT) 110 [RFC7858]. This includes an option for the client to 111 authenticate the server by means of an authentication domain name 112 [RFC8310]. 114 2. Provide an improved level of source address validation for DNS 115 servers compared to classic DNS over UDP [RFC1035]. 117 3. Provide a transport that is not constrained by path MTU 118 limitations on the size of DNS responses it can send. 120 4. Explore the potential performance gains of using QUIC as a DNS 121 transport, versus other solutions like DNS over UDP (DNS/UDP) 122 [RFC1035] or DoT [RFC7858]. 124 In order to achieve these goals, the focus of this document is 125 limited to the "stub to recursive resolver" scenario also addressed 126 by [RFC7858]. That is, the protocol described here works for queries 127 and responses between stub clients and recursive servers. The 128 specific non-goals of this document are: 130 1. No attempt is made to support zone transfers [RFC5936], as these 131 are not relevant to the stub to recursive resolver scenario. 133 2. No attempt is made to evade potential blocking of DNS/QUIC 134 traffic by middleboxes. 136 Users interested in zone transfers should continue using TCP based 137 solutions and will also want to take note of work in progress to 138 encrypt zone transfers using DoT [I-D.ietf-dprive-xfr-over-tls]. 139 Users interested in evading middleboxes should consider using 140 solutions like DNS/HTTPS [RFC8484]. 142 Specifying the transmission of an application over QUIC requires 143 specifying how the application's messages are mapped to QUIC streams, 144 and generally how the application will use QUIC. This is done for 145 HTTP in [I-D.ietf-quic-http]. The purpose of this document is to 146 define the way DNS messages can be transmitted over QUIC. 148 In this document, Section 3 presents the reasoning that guided the 149 proposed design. Section 4 specifies the actual mapping of DoQ. 150 Section 5 presents guidelines on the implementation, usage and 151 deployment of DoQ. 153 2. Key Words 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC8174]. 159 3. Design Considerations 161 This section and its subsection present the design guidelines that 162 were used for DoQ. This section is informative in nature. 164 3.1. Scope is Limited to the Stub to Resolver Scenario 166 Usage scenarios for the DNS protocol can be broadly classified in 167 three groups: stub to recursive resolver, recursive resolver to 168 authoritative server, and server to server. This design focuses only 169 on the "stub to recursive resolver" scenario following the approach 170 taken in [RFC7858] and [RFC8310]. 172 QUESTION: Should this document specify any aspects of configuration 173 of discoverability differently to DoT? 175 No attempt is made to address the recursive to authoritative 176 scenarios. Authoritative resolvers are discovered dynamically 177 through NS records. It is noted that at the time of writing work is 178 ongoing in the DPRIVE working group to attempt to address the 179 analogous problem for DoT [I-D.ietf-dprive-phase2-requirements]. In 180 the absence of an agreed way for authoritative to signal support for 181 QUIC transport, recursive resolvers would have to resort to some 182 trial and error process. At this stage of QUIC deployment, this 183 would be mostly errors, and does not seem attractive. This could 184 change in the future. 186 The DNS protocol is also used for zone transfers. In the zone 187 transfer scenario [RFC5936], the client emits a single AXFR query, 188 and the server responds with a series of AXFR responses. This 189 creates a unique profile, in which a query results in several 190 responses. Supporting that profile would complicate the mapping of 191 DNS queries over QUIC streams. Zone transfers are not used in the 192 stub to recursive scenario that is the focus here, and seem to be 193 currently well served by using DNS over TCP. There is no attempt to 194 support them in this proposed mapping of DNS to QUIC. 196 3.2. Provide DNS Privacy 198 DNS privacy considerations are described in [RFC7626]. [RFC7858] 199 defines how to mitigate some of these issues by transmitting DNS 200 messages over TLS and TCP and [RFC8310] specifies Strict and 201 Opportunistic Usage Profiles for DoT including how stub resolvers can 202 authenticate recursive resolvers. 204 QUIC connection setup includes the negotiation of security parameters 205 using TLS, as specified in [I-D.ietf-quic-tls], enabling encryption 206 of the QUIC transport. Transmitting DNS messages over QUIC will 207 provide essentially the same privacy protections as [RFC7858] and 208 [RFC8310]. Further discussion on this is provided in Section 7. 210 3.3. Design for Minimum Latency 212 QUIC is specifically designed to reduce the delay between HTTP 213 queries and HTTP responses. This is achieved through three main 214 components: 216 1. Support for 0-RTT data during session resumption. 218 2. Support for advanced error recovery procedures as specified in 219 [I-D.ietf-quic-recovery]. 221 3. Mitigation of head-of-line blocking by allowing parallel delivery 222 of data on multiple streams. 224 This mapping of DNS to QUIC will take advantage of these features in 225 three ways: 227 1. Optional support for sending 0-RTT data during session resumption 228 (the security and privacy implications of this are discussed in 229 later sections). 231 2. Long-lived QUIC connections over which multiple DNS transactions 232 are performed, generating the sustained traffic required to 233 benefit from advanced recovery features. 235 3. Fast resumption of QUIC connections to manage the disconnect-on- 236 idle feature of QUIC without incurring retransmission time-outs. 238 4. Mapping of each DNS Query/Response transaction to a separate 239 stream, to mitigate head-of-line blocking. 241 These considerations will be reflected in the mapping of DNS traffic 242 to QUIC streams in Section 4.2. 244 3.4. No Specific Middlebox Bypass Mechanism 246 The mapping of DNS over QUIC is defined for minimal overhead and 247 maximum performance. This means a different traffic profile than 248 HTTP over QUIC. This difference can be noted by firewalls and 249 middleboxes. There may be environments in which HTTP/QUIC will be 250 allowed, but DoQ will be disallowed and blocked by these middle 251 boxes. 253 It is recognized that this might be a problem, but there is currently 254 no indication on how widespread that problem might be. The problem 255 might be acute enough that the only realistic solution would be to 256 communicate with independent recursive resolvers using DNS/HTTPS, or 257 maybe DNS/HTTP/QUIC. Or the problem might be rare enough and the 258 performance gains significant enough that the appropriate solution 259 would be to use DoQ most of the time, and fall back to DNS/HTTPS some 260 of the time. Measurements and experimentation will inform that 261 decision. 263 It may indeed turn out that the complexity and overhead concerns are 264 negligible compared to the potential advantages of DNS/HTTPS, such as 265 integration with web services or firewall traversal, and that DoQ 266 does not provide sufficient performance gains to justify a new 267 protocol. We will evaluate that once implementations are available 268 and can be compared. 270 4. Specifications 272 4.1. Connection Establishment 274 DoQ connections are established as described in 275 [I-D.ietf-quic-transport]. During connection establishment, DoQ 276 support is indicated by selecting the ALPN token "dq" in the crypto 277 handshake. 279 4.1.1. Draft Version Identification 281 *RFC Editor's Note:* Please remove this section prior to publication 282 of a final version of this document. 284 Only implementations of the final, published RFC can identify 285 themselves as "doq". Until such an RFC exists, implementations MUST 286 NOT identify themselves using this string. 288 Implementations of draft versions of the protocol MUST add the string 289 "-" and the corresponding draft number to the identifier. For 290 example, draft-huitema-dprive-dnsoquic-00 is identified using the 291 string "doq-h00". 293 4.1.2. Port Selection 295 By default, a DNS server that supports DoQ MUST listen for and accept 296 QUIC connections on the dedicated UDP port TBD (number to be defined 297 in Section 8, unless it has mutual agreement with its clients to use 298 a port other than TBD for DoQ. In order to use a port other than 299 TBD, both clients and servers would need a configuration option in 300 their software. 302 By default, a DNS client desiring to use DoQ with a particular server 303 MUST establish a QUIC connection to UDP port TBD on the server, 304 unless it has mutual agreement with its server to use a port other 305 than port TBD for DoQ. Such another port MUST NOT be port 53 or port 306 853. This recommendation against use of port 53 for DoQ is to avoid 307 confusion between DoQ and DNS/UDP as specified in [RFC1035]. 308 Similarly, using port 853 would cause confusion between DoQ and DNS/ 309 DTLS as specified in [RFC8094]. 311 4.2. Stream Mapping and Usage 313 The mapping of DNS traffic over QUIC streams takes advantage of the 314 QUIC stream features detailed in Section 2 of 315 [I-D.ietf-quic-transport]. 317 The stub to resolver DNS traffic follows a simple pattern in which 318 the client sends a query, and the server provides a response. This 319 design specifies that for each subsequent query on a QUIC connection 320 the client MUST select the next available client-initiated 321 bidirectional stream, in conformance with [I-D.ietf-quic-transport]. 323 The client MUST send the DNS query over the selected stream, and MUST 324 indicate through the STREAM FIN mechanism that no further data will 325 be sent on that stream. 327 The server MUST send the response on the same stream, and MUST 328 indicate through the STREAM FIN mechanism that no further data will 329 be sent on that stream. 331 Therefore, a single client initiated DNS transaction consumes a 332 single stream. This means that the client's first query occurs on 333 QUIC stream 0, the second on 4, and so on. 335 4.2.1. Server Initiated Transactions 337 There are planned traffic patterns in which a server sends 338 unsolicited queries to a client, such as for example PUSH messages 339 defined in [I-D.ietf-dnssd-push]. These occur when a client 340 subscribes to changes for a particular DNS RRset or resource record 341 type. When a PUSH server wishes to send such updates it MUST select 342 the next available server initiated bidirectional stream, in 343 conformance with [I-D.ietf-quic-transport]. 345 The server MUST send the DNS query over the selected stream, and MUST 346 indicate through the STREAM FIN mechanism that no further data will 347 be sent on that stream. 349 The client MUST send the response on the same stream, and MUST 350 indicate through the STREAM FIN mechanism that no further data will 351 be sent on that stream. 353 Therefore a single server initiated DNS transaction consumes a single 354 stream. This means that the servers's first query occurs on QUIC 355 stream 1, the second on 5, and so on. 357 4.2.2. Stream Reset 359 Stream transmission may be abandoned by either party, using the 360 stream "reset" facility. A stream reset indicates that one party is 361 unwilling to continue processing the transaction associated with the 362 stream. The corresponding transaction MUST be abandoned. A Server 363 Failure (SERVFAIL, [RFC1035]) SHOULD be notified to the initiator of 364 the transaction. 366 4.3. Connection Management 368 Section 10 of the QUIC transport specifications 369 [I-D.ietf-quic-transport] specifies that connections can be closed in 370 three ways: 372 o idle timeout 374 o immediate close 376 o stateless reset 378 Clients and servers implementing DNS over QUIC SHOULD negotiate use 379 of the idle timeout. Closing on idle-timeout is done without any 380 packet exchange, which minimizes protocol overhead. This document 381 does not recommend a specific value of the idle timer. 383 Clients SHOULD monitor the idle time incurred on their connection to 384 the server, defined by the time spend since the last packet from the 385 server has been received. When a client prepares to send a new DNS 386 query to the server, it will check whether the idle time is 387 sufficient lower than the idle timer. If it is, the client will send 388 the DNS query over the existing connection. If not, the client will 389 establish a new connection and send the query over that connection. 391 Clients MAY discard their connection to the server before the idle 392 timeout expires. If they do that, they SHOULD close the connection 393 explicitly, using QUIC's CONNECTION_CLOSE mechanisms, and indicating 394 the Application reason "No Error". 396 Clients and servers may close the connection for a variety of other 397 reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers 398 that send packets over a connection discarded by their peer MAY 399 receive a stateless reset indication. If a connection fails, all 400 queries in progress over the connection MUST be considered failed, 401 and aServer Failure (SERVFAIL, [RFC1035]) SHOULD be notified to the 402 initiator of the transaction. 404 4.4. Connection Resume and 0-RTT 406 A stub resolver MAY take advantage of the connection resume 407 mechanisms supported by QUIC transport [I-D.ietf-quic-transport] and 408 QUIC TLS [I-D.ietf-quic-tls]. Stub resolvers SHOULD consider 409 potential privacy issues associated with session resume before 410 deciding to use this mechanism. These privacy issues are detailed in 411 Section 7.2. 413 When resuming a session, a stub resolver MAY take advantage of the 414 0-RTT mechanism supported by QUIC. The 0-RTT mechanism MUST NOT be 415 used to send data that is not "replayable" transactions. For 416 example, a stub resolver MAY transmit a Query as 0-RTT, but MUST NOT 417 transmit an Update. 419 5. Implementation Requirements 421 5.1. Authentication 423 For the stub to recursive resolver scenario, the authentication 424 requirements are the same as described in [RFC7858] and [RFC8310]. 425 There is no need to authenticate the client's identity in either 426 scenario. 428 5.2. Fall Back to Other Protocols on Connection Failure 430 If the establishment of the DoQ connection fails, clients SHOULD 431 attempt to fall back to DoT and then potentially clear text, as 432 specified in [RFC7858] and [RFC8310], depending on their privacy 433 profile. 435 DNS clients SHOULD remember server IP addresses that don't support 436 DoQ, including timeouts, connection refusals, and QUIC handshake 437 failures, and not request DoQ from them for a reasonable period (such 438 as one hour per server). DNS clients following an out-of-band key- 439 pinned privacy profile ([RFC7858]) MAY be more aggressive about 440 retrying DoQ connection failures. 442 5.3. Address Validation 444 The QUIC transport specification defines Address Validation 445 procedures to avoid servers being used in address amplification 446 attacks (see section 8 of [I-D.ietf-quic-transport]). DoQ 447 implementations MUST conform to this specification, which limits the 448 worst case amplification to a factor 3. 450 DoQ implementations SHOULD consider configuring servers to use the 451 Address Validation using Retry Packets procedure defined in section 452 8.1.2 of [I-D.ietf-quic-transport]). This procedure imposes a 1-RTT 453 delay for verifying the return routability of the source address of a 454 client, similar to the DNS Cookies mechanism defined in [RFC7873]. 456 DoQ implementations that configure Address Validation using Retry 457 Packets SHOULD implement the Address Validation for Future 458 Connections procedure defined in section 8.1.3 of 459 [I-D.ietf-quic-transport]). This define how servers can send NEW 460 TOKEN frames to clients after the client address is validated, in 461 order to avoid the 1-RTT penalty during subsequent connections by the 462 client from the same address. 464 5.4. Response Sizes 466 DoQ does not suffer from the same limitations on the size of queries 467 and responses that as DNS/UDP [RFC1035] does. Queries and Responses 468 are sent on QUIC streams, which in theory can carry up to 2^62 bytes. 469 However, clients or servers MAY impose a limit on the maximum size of 470 data that they can accept over a given stream. This is controlled in 471 QUIC by the transport parameters: 473 o initial_max_stream_data_bidi_local: when set by the client, 474 specifies the amount of data that servers can send on a "response" 475 stream without waiting for a MAX_STREAM_DATA frame. 477 o initial_max_stream_data_bidi_remote: when set by the server, 478 specifies the amount of data that clients can send on a "query" 479 stream without waiting for a MAX_STREAM_DATA frame. 481 Clients and servers SHOULD treat these parameters as the practical 482 maximum of queries and responses. If the EDNS parameters of a Query 483 indicate a lower message size, servers MUST comply with that 484 indication. 486 5.5. DNS Message IDs 488 When sending queries over a QUIC connection, the DNS Message ID MUST 489 be set to zero. 491 5.6. Padding 493 There are mechanisms specified for both padding individual DNS 494 messages [RFC7830], [RFC8467] and padding within QUIC packets (see 495 Section 8.6 of [I-D.ietf-quic-transport]), which may contain multiple 496 frames. 498 Implementations SHOULD NOT use DNS options for padding individual DNS 499 messages, because QUIC transport MAY transmit multiple STREAM frames 500 containing separate DNS messages in a single QUIC packet. Instead, 501 implementations SHOULD use QUIC PADDING frames to align the packet 502 length to a small set of fixed sizes, aligned with the 503 recommendations of [RFC8467]. 505 5.7. Connection Handling 507 [RFC7766] provides updated guidance on DNS/TCP much of which is 508 applicable to DoQ. This section attempts to specify how those 509 considerations apply to DoQ. 511 5.7.1. Connection Reuse 513 Historic implementations of DNS stub resolvers are known to open and 514 close TCP connections for each DNS query. To avoid excess QUIC 515 connections, each with a single query, clients SHOULD reuse a single 516 QUIC connection to the recursive resolver. 518 In order to achieve performance on par with UDP, DNS clients SHOULD 519 send their queries concurrently over the QUIC streams on a QUIC 520 connection. That is, when a DNS client sends multiple queries to a 521 server over a QUIC connection, it SHOULD NOT wait for an outstanding 522 reply before sending the next query. 524 5.7.2. Connection Close 526 In order to amortize QUIC and TLS connection setup costs, clients and 527 servers SHOULD NOT immediately close a QUIC connection after each 528 response. Instead, clients and servers SHOULD reuse existing QUIC 529 connections for subsequent queries as long as they have sufficient 530 resources. In some cases, this means that clients and servers may 531 need to keep idle connections open for some amount of time. 533 Under normal operation DNS clients typically initiate connection 534 closing on idle connections; however, DNS servers can close the 535 connection if the idle timeout set by local policy is exceeded. 536 Also, connections can be closed by either end under unusual 537 conditions such as defending against an attack or system failure/ 538 reboot. 540 Clients and servers that keep idle connections open MUST be robust to 541 termination of idle connection by either party. As with current DNS 542 over TCP, DNS servers MAY close the connection at any time (perhaps 543 due to resource constraints). As with current DNS/TCP, clients MUST 544 handle abrupt closes and be prepared to reestablish connections and/ 545 or retry queries. 547 5.7.3. Idle Timeouts 549 Proper management of established and idle connections is important to 550 the healthy operation of a DNS server. An implementation of DoQ 551 SHOULD follow best practices for DNS/TCP, as described in [RFC7766]. 552 Failure to do so may lead to resource exhaustion and denial of 553 service. 555 This document does not make specific recommendations for timeout 556 values on idle connections. Clients and servers should reuse and/or 557 close connections depending on the level of available resources. 558 Timeouts may be longer during periods of low activity and shorter 559 during periods of high activity. Current work in this area may also 560 assist DoT clients and servers in selecting useful timeout values 561 [RFC7828] [RFC8490] [TDNS]. 563 Clients that are willing to use QUIC's 0-RTT mechanism can 564 reestablish connections and send transactions on the new connection 565 with minimal delay overhead. These clients MAY chose low values of 566 the idle timer, but SHOULD NOT pick value lower than 20 seconds. 568 Per section 10.2 of QUIC transport specification, the effective value 569 of the idle timeout is computed as the minimum of the values 570 advertised by the two endpoints. 572 5.8. Flow Control Mechanisms 574 Servers and Clients manage flow control as specified in QUIC. 576 Servers MAY use the "maximum stream ID" option of the QUIC transport 577 to limit the number of streams opened by the client. This mechanism 578 will effectively limit the number of DNS queries that a client can 579 send. 581 6. Security Considerations 583 The security considerations of DoQ should be comparable to those of 584 DoT [RFC7858]. 586 7. Privacy Considerations 588 DoQ is specifically designed to protect the DNS traffic between stub 589 and resolver from observations by third parties, and thus protect the 590 privacy of queries from the stub. However, the recursive resolver 591 has full visibility of the stub's traffic, and could be used as an 592 observation point, as discussed in [I-D.ietf-dprive-rfc7626-bis]. 593 These considerations do not differ between DoT and DoQ and are not 594 discussed further here. 596 QUIC incorporates the mechanisms of TLS 1.3 [RFC8446] and this 597 enables QUIC transmission of "Zero-RTT" data. This can provide 598 interesting latency gains, but it raises two concerns: 600 1. Adversaries could replay the zero-RTT data and infer its content 601 from the behavior of the receiving server. 603 2. The zero-RTT mechanism relies on TLS resume, which can provide 604 linkability between successive client sessions. 606 These issues are developed in Section 7.1 and Section 7.2. 608 7.1. Privacy Issues With Zero RTT data 610 The zero-RTT data can be replayed by adversaries. That data may 611 triggers a query by a recursive resolver to an authoritative 612 resolvers. Adversaries may be able to pick a time at which the 613 recursive resolver outgoing traffic is observable, and thus find out 614 what name was queried for in the 0-RTT data. 616 This risk is in fact a subset of the general problem of observing the 617 behavior of the recursive resolver discussed in [RFC7626]. The 618 attack is partially mitigated by reducing the observability of this 619 traffic. However, the risk is amplified for 0-RTT data, because the 620 attacker might replay it at chosen times, several times. 622 The recommendation in [RFC8446] is that the capability to use 0-RTT 623 data should be turned off by default, on only enabled if the user 624 clearly understands the associated risks. 626 QUESTION: Should 0-RTT only be used with Opportunistic profiles (i.e. 627 disabled by default for Strict only)? 629 7.2. Privacy Issues With Session Resume 631 The QUIC session resume mechanism reduces the cost of reestablishing 632 sessions and enables zero-RTT data. There is a linkability issue 633 associated with session resume, if the same resume token is used 634 several times, but this risk is mitigated by the mechanisms 635 incorporated in QUIC and in TLS 1.3. With these mechanisms, clients 636 and servers can cooperate to avoid linkability by third parties. 637 However, the server will always be able to link the resumed session 638 to the initial session. This creates a virtual long duration 639 session. The series of queries in that session can be used by the 640 server to identify the client. 642 Enabling the server to link client sessions through session resume is 643 probably not a large additional risk if the client's connectivity did 644 not change between the sessions, since the two sessions can probably 645 be correlated by comparing the IP addresses. On the other hand, if 646 the addresses did change, the client SHOULD consider whether the 647 linkability risk exceeds the privacy benefits. This evaluation will 648 obviously depend on the level of trust between stub and recursive. 650 7.3. Traffic Analysis 652 Even though QUIC packets are encrypted, adversaries can gain 653 information from observing packet lengths, in both queries and 654 responses, as well as packet timing. Many DNS requests are emitted 655 by web browsers. Loading a specific web page may require resolving 656 dozen of DNS names. If an application adopts a simple mapping of one 657 query or response per packet, or "one QUIC STREAM frame per packet", 658 then the succession of packet lengths may provide enough information 659 to identify the requested site. 661 Implementations SHOULD use the mechanisms defined in Section 5.6 to 662 mitigate this attack. 664 8. IANA Considerations 666 8.1. Registration of DoQ Identification String 668 This document creates a new registration for the identification of 669 DoQ in the "Application Layer Protocol Negotiation (ALPN) Protocol 670 IDs" registry established in [RFC7301]. 672 The "doq" string identifies DoQ: 674 Protocol: DoQ 676 Identification Sequence: 0x64 0x71 ("dq") 678 Specification: This document 680 8.2. Reservation of Dedicated Port 682 IANA is required to add the following value to the "Service Name and 683 Transport Protocol Port Number Registry" in the System Range. The 684 registry for that range requires IETF Review or IESG Approval 685 {{?RFC6335], and such a review was requested using the early 686 allocation process {{?RFC7120] for the well-known UDP port in this 687 document. Since port 853 is reserved for 'DNS query-response 688 protocol run over TLS' consideration is requested for reserving port 689 TBD for 'DNS query-response 690 protocol run over QUIC'. 692 Service Name domain-s 693 Transport Protocol(s) TCP/UDP 694 Assignee IESG 695 Contact IETF Chair 696 Description DNS query-response protocol run over QUIC 697 Reference This document 699 8.2.1. Port number 784 for experimentations 701 *RFC Editor's Note:* Please remove this section prior to publication 702 of a final version of this document. 704 Early experiments MAY use port 784. This port is marked in the IANA 705 registry as unassigned. 707 9. Acknowledgements 709 This document liberally borrows text from [I-D.ietf-quic-http] edited 710 by Mike Bishop, and from [RFC7858] authored by Zi Hu, Liang Zhu, John 711 Heidemann, Allison Mankin, Duane Wessels, and Paul Hoffman. 713 The privacy issue with 0-RTT data and session resume were analyzed by 714 Daniel Kahn Gillmor (DKG) in a message to the IETF "DPRIV" working 715 group [DNS0RTT]. 717 Thanks to our wide cast of supporters. 719 10. References 721 10.1. Normative References 723 [I-D.ietf-dnsop-terminology-ter] 724 Hoffman, P., "Terminology for DNS Transports and 725 Location", draft-ietf-dnsop-terminology-ter-01 (work in 726 progress), February 2020. 728 [I-D.ietf-quic-tls] 729 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 730 draft-ietf-quic-tls-27 (work in progress), February 2020. 732 [I-D.ietf-quic-transport] 733 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 734 and Secure Transport", draft-ietf-quic-transport-27 (work 735 in progress), February 2020. 737 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 738 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 739 . 741 [RFC1035] Mockapetris, P., "Domain names - implementation and 742 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 743 November 1987, . 745 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 746 "Transport Layer Security (TLS) Application-Layer Protocol 747 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 748 July 2014, . 750 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 751 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 752 . 754 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 755 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 756 May 2017, . 758 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 759 for DNS over TLS and DNS over DTLS", RFC 8310, 760 DOI 10.17487/RFC8310, March 2018, 761 . 763 10.2. Informative References 765 [DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG 766 mailing list, April 2016, . 769 [I-D.ietf-dnssd-push] 770 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 771 draft-ietf-dnssd-push-25 (work in progress), October 2019. 773 [I-D.ietf-dprive-phase2-requirements] 774 Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS 775 Privacy Requirements for Exchanges between Recursive 776 Resolvers and Authoritative Servers", draft-ietf-dprive- 777 phase2-requirements-00 (work in progress), December 2019. 779 [I-D.ietf-dprive-rfc7626-bis] 780 Bortzmeyer, S. and S. Dickinson, "DNS Privacy 781 Considerations", draft-ietf-dprive-rfc7626-bis-04 (work in 782 progress), January 2020. 784 [I-D.ietf-dprive-xfr-over-tls] 785 Zhang, H., Aras, P., Toorop, W., Dickinson, S., and A. 786 Mankin, "DNS Zone Transfer-over-TLS", draft-ietf-dprive- 787 xfr-over-tls-00 (work in progress), November 2019. 789 [I-D.ietf-quic-http] 790 Bishop, M., "Hypertext Transfer Protocol Version 3 791 (HTTP/3)", draft-ietf-quic-http-27 (work in progress), 792 February 2020. 794 [I-D.ietf-quic-recovery] 795 Iyengar, J. and I. Swett, "QUIC Loss Detection and 796 Congestion Control", draft-ietf-quic-recovery-26 (work in 797 progress), February 2020. 799 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 800 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 801 . 803 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 804 DOI 10.17487/RFC7626, August 2015, 805 . 807 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 808 D. Wessels, "DNS Transport over TCP - Implementation 809 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 810 . 812 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 813 edns-tcp-keepalive EDNS0 Option", RFC 7828, 814 DOI 10.17487/RFC7828, April 2016, 815 . 817 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 818 DOI 10.17487/RFC7830, May 2016, 819 . 821 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 822 and P. Hoffman, "Specification for DNS over Transport 823 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 824 2016, . 826 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 827 Transport Layer Security (DTLS)", RFC 8094, 828 DOI 10.17487/RFC8094, February 2017, 829 . 831 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 832 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 833 . 835 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 836 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 837 October 2018, . 839 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 840 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 841 . 843 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 844 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 845 RFC 8490, DOI 10.17487/RFC8490, March 2019, 846 . 848 [TDNS] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., 849 and N. Somaiya, "Connection-Oriented DNS to Improve 850 Privacy and Security", 2015 IEEE Symposium on Security and 851 Privacy (SP), DOI 10.1109/SP.2015.18, May 2015, 852 . 854 Authors' Addresses 856 Christian Huitema 857 Private Octopus Inc. 858 427 Golfcourse Rd 859 Friday Harbor WA 98250 860 U.S.A 862 Email: huitema@huitema.net 864 Allison Mankin 865 Salesforce 867 Email: amankin@salesforce.com 869 Sara Dickinson 870 Sinodun IT 871 Oxford Science Park 872 Oxford OX4 4GA 873 U.K. 875 Email: sara@sinodun.com