idnits 2.17.1 draft-ietf-dprive-dnsoquic-01.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 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 (October 20, 2020) is 1274 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) -- 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-31 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-31 == Outdated reference: A later version (-02) exists of draft-ietf-dprive-phase2-requirements-01 == Outdated reference: A later version (-09) exists of draft-ietf-dprive-rfc7626-bis-07 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-xfr-over-tls-02 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-31 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-31 -- Obsolete informational reference (is this intentional?): RFC 1885 (Obsoleted by RFC 2463) -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 4 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: April 23, 2021 Salesforce 6 S. Dickinson 7 Sinodun IT 8 October 20, 2020 10 Specification of DNS over Dedicated QUIC Connections 11 draft-ietf-dprive-dnsoquic-01 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 latency 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 http://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 April 23, 2021. 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 (http://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 3.5. No Server Initiated Transactions . . . . . . . . . . . . 6 65 4. Specifications . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Connection Establishment . . . . . . . . . . . . . . . . 7 67 4.1.1. Draft Version Identification . . . . . . . . . . . . 7 68 4.1.2. Port Selection . . . . . . . . . . . . . . . . . . . 7 69 4.2. Stream Mapping and Usage . . . . . . . . . . . . . . . . 7 70 4.2.1. Transaction Errors . . . . . . . . . . . . . . . . . 8 71 4.3. DoQ Error Codes . . . . . . . . . . . . . . . . . . . . . 8 72 4.4. Connection Management . . . . . . . . . . . . . . . . . . 9 73 4.5. Connection Resume and 0-RTT . . . . . . . . . . . . . . . 9 74 4.6. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 10 75 5. Implementation Requirements . . . . . . . . . . . . . . . . . 10 76 5.1. Authentication . . . . . . . . . . . . . . . . . . . . . 10 77 5.2. Fall Back to Other Protocols on Connection Failure . . . 11 78 5.3. Address Validation . . . . . . . . . . . . . . . . . . . 11 79 5.4. DNS Message IDs . . . . . . . . . . . . . . . . . . . . . 11 80 5.5. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 5.6. Connection Handling . . . . . . . . . . . . . . . . . . . 12 82 5.6.1. Connection Reuse . . . . . . . . . . . . . . . . . . 12 83 5.6.2. Resource Management and Idle Timeout Values . . . . . 12 84 5.7. Processing Queries in Parallel . . . . . . . . . . . . . 13 85 5.8. Flow Control Mechanisms . . . . . . . . . . . . . . . . . 13 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 88 7.1. Privacy Issues With 0-RTT data . . . . . . . . . . . . . 14 89 7.2. Privacy Issues With Session Resume . . . . . . . . . . . 14 90 7.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 15 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 92 8.1. Registration of DoQ Identification String . . . . . . . . 15 93 8.2. Reservation of Dedicated Port . . . . . . . . . . . . . . 15 94 8.2.1. Port number 784 for experimentations . . . . . . . . 16 95 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 98 10.2. Informative References . . . . . . . . . . . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 101 1. Introduction 103 Domain Name System (DNS) concepts are specified in "Domain names - 104 concepts and facilities" [RFC1034]. The transmission of DNS queries 105 and responses over UDP and TCP is specified in "Domain names - 106 implementation and specification" [RFC1035]. This document presents 107 a mapping of the DNS protocol over the QUIC transport 108 [I-D.ietf-quic-transport] [I-D.ietf-quic-tls]. DNS over QUIC is 109 referred here as DoQ, in line with the "Terminology for DNS 110 Transports and Location" [I-D.ietf-dnsop-terminology-ter]. The goals 111 of the DoQ mapping are: 113 1. Provide the same DNS privacy protection as DNS over TLS (DoT) 114 [RFC7858]. This includes an option for the client to 115 authenticate the server by means of an authentication domain name 116 as specified in "Usage Profiles for DNS over TLS and DNS over 117 DTLS" [RFC8310]. 119 2. Provide an improved level of source address validation for DNS 120 servers compared to classic DNS over UDP. 122 3. Provide a transport that is not constrained by path MTU 123 limitations on the size of DNS responses it can send. 125 4. Explore the characteristics of using QUIC as a DNS transport, 126 versus other solutions like DNS over UDP [RFC1035], DoT 127 [RFC7858], or DNS over HTTPS (DoH) [RFC8484]. 129 In order to achieve these goals, the focus of this document is 130 limited to the "stub to recursive resolver" scenario also addressed 131 by DoT [RFC7858]. That is, the protocol described here works for 132 queries and responses between stub clients and recursive servers. 133 The specific non-goals of this document are: 135 1. No attempt is made to support AXFR "DNS Zone Transfer Protocol 136 (AXFR)" [RFC5936] or IXFR "Incremental Zone Transfer in DNS" 137 [RFC1885], as these mechanisms are not relevant to the stub to 138 recursive resolver scenario. 140 2. No attempt is made to evade potential blocking of DNS over QUIC 141 traffic by middleboxes. 143 3. No attempt to support server initiated transactions, are these 144 are not relevant for the "stub to recursive resolver" scenario, 145 see Section 3.5. 147 Users interested in zone transfers should continue using TCP based 148 solutions and will also want to take note of work in progress to 149 support "DNS Zone Transfer-over-TLS" [I-D.ietf-dprive-xfr-over-tls]. 151 Specifying the transmission of an application over QUIC requires 152 specifying how the application's messages are mapped to QUIC streams, 153 and generally how the application will use QUIC. This is done for 154 HTTP in "Hypertext Transfer Protocol Version 3 155 (HTTP/3)"[I-D.ietf-quic-http]. The purpose of this document is to 156 define the way DNS messages can be transmitted over QUIC. 158 In this document, Section 3 presents the reasoning that guided the 159 proposed design. Section 4 specifies the actual mapping of DoQ. 160 Section 5 presents guidelines on the implementation, usage and 161 deployment of DoQ. 163 2. Key Words 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in BCP 14 [RFC8174]. 169 3. Design Considerations 171 This section and its subsection present the design guidelines that 172 were used for DoQ. This section is informative in nature. 174 3.1. Scope is Limited to the Stub to Resolver Scenario 176 Usage scenarios for the DNS protocol can be broadly classified in 177 three groups: stub to recursive resolver, recursive resolver to 178 authoritative server, and server to server. This design focuses only 179 on the "stub to recursive resolver" scenario following the approach 180 taken in DoT [RFC7858] and "Usage Profiles for DNS over TLS and DNS 181 over DTLS" [RFC8310]. 183 QUESTION: Should this document specify any aspects of configuration 184 of discoverability differently to DoT? 186 No attempt is made to address the recursive to authoritative 187 scenarios. Authoritative resolvers are discovered dynamically 188 through NS records. It is noted that at the time of writing work is 189 ongoing in the DPRIVE working group to attempt to address the 190 analogous problem for DoT [I-D.ietf-dprive-phase2-requirements]. In 191 the absence of an agreed way for authoritative to signal support for 192 QUIC transport, recursive resolvers would have to resort to some 193 trial and error process. At this stage of QUIC deployment, this 194 would be mostly errors, and does not seem attractive. This could 195 change in the future. 197 The DNS protocol is also used for zone transfers. In the AXFR zone 198 transfer scenario [RFC5936], the client emits a single AXFR query, 199 and the server responds with a series of AXFR responses. This 200 creates a unique profile, in which a query results in several 201 responses. Supporting that profile would complicate the mapping of 202 DNS queries over QUIC streams. Zone transfers are not used in the 203 stub to recursive scenario that is the focus here, and seem to be 204 currently well served by using DNS over TCP. There is no attempt to 205 support either AXFR or IXFR in this proposed mapping of DNS to QUIC. 207 3.2. Provide DNS Privacy 209 DoT [RFC7858] defines how to mitigate some of the issues described in 210 "DNS Privacy Considerations" [RFC7626] by specifying how to transmit 211 DNS messages over TLS. The "Usage Profiles for DNS over TLS and DNS 212 over DTLS" [RFC8310] specify Strict and Opportunistic Usage Profiles 213 for DoT including how stub resolvers can authenticate recursive 214 resolvers. 216 QUIC connection setup includes the negotiation of security parameters 217 using TLS, as specified in "Using TLS to Secure QUIC" 218 [I-D.ietf-quic-tls], enabling encryption of the QUIC transport. 219 Transmitting DNS messages over QUIC will provide essentially the same 220 privacy protections as DoT [RFC7858] including Strict and 221 Opportunistic Usage Profiles [RFC8310]. Further discussion on this 222 is provided in Section 7. 224 3.3. Design for Minimum Latency 226 QUIC is specifically designed to reduce the delay between HTTP 227 queries and HTTP responses. This is achieved through three main 228 components: 230 1. Support for 0-RTT data during session resumption. 232 2. Support for advanced error recovery procedures as specified in 233 "QUIC Loss Detection and Congestion Control" 234 [I-D.ietf-quic-recovery]. 236 3. Mitigation of head-of-line blocking by allowing parallel delivery 237 of data on multiple streams. 239 This mapping of DNS to QUIC will take advantage of these features in 240 three ways: 242 1. Optional support for sending 0-RTT data during session resumption 243 (the security and privacy implications of this are discussed in 244 later sections). 246 2. Long-lived QUIC connections over which multiple DNS transactions 247 are performed, generating the sustained traffic required to 248 benefit from advanced recovery features. 250 3. Fast resumption of QUIC connections to manage the disconnect-on- 251 idle feature of QUIC without incurring retransmission time-outs. 253 4. Mapping of each DNS Query/Response transaction to a separate 254 stream, to mitigate head-of-line blocking. This enables servers 255 to respond to queries "out of order". It also enables clients to 256 process responses as soon as they arrive, without having to wait 257 for in order delivery of responses previously posted by the 258 server. 260 These considerations will be reflected in the mapping of DNS traffic 261 to QUIC streams in Section 4.2. 263 3.4. No Specific Middlebox Bypass Mechanism 265 The mapping of DNS over QUIC is defined for minimal overhead and 266 maximum performance. This means a different traffic profile than 267 HTTP3 over QUIC. This difference can be noted by firewalls and 268 middleboxes. There may be environments in which HTTP3 over QUIC will 269 be able to pass through, but DoQ will be blocked by these middle 270 boxes. 272 3.5. No Server Initiated Transactions 274 As stated in Section 1, this document does not specify support for 275 server initiated transactions because these are not relevant for the 276 "stub to recursive resolver" scenario. Note that "DNS Stateful 277 Operations" (DSO) [RFC8490] are only applicable for DNS over TCP and 278 DNS over TLS. DSO is not applicable to DNS over HTTP since HTTP has 279 its own mechanism for managing sessions, and this is incompatible 280 with the DSO; the same is true for DNS over QUIC. 282 4. Specifications 283 4.1. Connection Establishment 285 DoQ connections are established as described in the QUIC transport 286 specification [I-D.ietf-quic-transport]. During connection 287 establishment, DoQ support is indicated by selecting the ALPN token 288 "doq" in the crypto handshake. 290 4.1.1. Draft Version Identification 292 *RFC Editor's Note:* Please remove this section prior to publication 293 of a final version of this document. 295 Only implementations of the final, published RFC can identify 296 themselves as "doq". Until such an RFC exists, implementations MUST 297 NOT identify themselves using this string. 299 Implementations of draft versions of the protocol MUST add the string 300 "-" and the corresponding draft number to the identifier. For 301 example, draft-ietf-dprive-dnsoquic-00 is identified using the string 302 "doq-i00". 304 4.1.2. Port Selection 306 By default, a DNS server that supports DoQ MUST listen for and accept 307 QUIC connections on the dedicated UDP port TBD (number to be defined 308 in Section 8), unless it has mutual agreement with its clients to use 309 a port other than TBD for DoQ. In order to use a port other than 310 TBD, both clients and servers would need a configuration option in 311 their software. 313 By default, a DNS client desiring to use DoQ with a particular server 314 MUST establish a QUIC connection to UDP port TBD on the server, 315 unless it has mutual agreement with its server to use a port other 316 than port TBD for DoQ. Such another port MUST NOT be port 53 or port 317 853. This recommendation against use of port 53 for DoQ is to avoid 318 confusion between DoQ and the use of DNS over UDP [RFC1035]. 319 Similarly, using port 853 would cause confusion between DoQ and DNS 320 over DTLS [RFC8094]. 322 4.2. Stream Mapping and Usage 324 The mapping of DNS traffic over QUIC streams takes advantage of the 325 QUIC stream features detailed in Section 2 of the QUIC transport 326 specification [I-D.ietf-quic-transport]. 328 The stub to resolver DNS traffic follows a simple pattern in which 329 the client sends a query, and the server provides a response. This 330 design specifies that for each subsequent query on a QUIC connection 331 the client MUST select the next available client-initiated 332 bidirectional stream, in conformance with the QUIC transport 333 specification [I-D.ietf-quic-transport]. 335 The client MUST send the DNS query over the selected stream, and MUST 336 indicate through the STREAM FIN mechanism that no further data will 337 be sent on that stream. 339 The server MUST send the response on the same stream, and MUST 340 indicate through the STREAM FIN mechanism that no further data will 341 be sent on that stream. 343 Therefore, a single client initiated DNS transaction consumes a 344 single stream. This means that the client's first query occurs on 345 QUIC stream 0, the second on 4, and so on. 347 4.2.1. Transaction Errors 349 Peers normally complete transactions by sending a DNS response on the 350 transaction's stream, including cases where the DNS response 351 indicates a DNS error. For example, a Server Failure (SERVFAIL, 352 [RFC1035]) SHOULD be notified to the initiator of the transaction by 353 sending back a response with the Response Code set to SERVFAIL. 355 If a peer is incapable of sending a DNS response due to an internal 356 error, it may issue a QUIC Stream Reset with error code 357 DOQ_INTERNAL_ERROR. The corresponding transaction MUST be abandoned. 359 4.3. DoQ Error Codes 361 The following error codes are defined for use when abruptly 362 terminating streams, aborting reading of streams, or immediately 363 closing connections: 365 DOQ_NO_ERROR (0x00): No error. This is used when the connection or 366 stream needs to be closed, but there is no error to signal. 368 DOQ_INTERNAL_ERROR (0x01): The DoQ implementation encountered an 369 internal error and is incapable of pursuing the transaction or the 370 connection. 372 DOQ_TRANSPORT_PARAMETER_ERROR (0x02): One or some of the transport 373 parameters proposed by the peer are not acceptable. 375 4.4. Connection Management 377 Section 10 of the QUIC transport specification 378 [I-D.ietf-quic-transport] specifies that connections can be closed in 379 three ways: 381 o idle timeout 383 o immediate close 385 o stateless reset 387 Clients and servers implementing DNS over QUIC SHOULD negotiate use 388 of the idle timeout. Closing on idle timeout is done without any 389 packet exchange, which minimizes protocol overhead. Per section 10.2 390 of the QUIC transport specification, the effective value of the idle 391 timeout is computed as the minimum of the values advertised by the 392 two endpoints. Practical considerations on setting the idle timeout 393 are discussed in Section 5.6.2. 395 Clients SHOULD monitor the idle time incurred on their connection to 396 the server, defined by the time spent since the last packet from the 397 server has been received. When a client prepares to send a new DNS 398 query to the server, it will check whether the idle time is 399 sufficient lower than the idle timer. If it is, the client will send 400 the DNS query over the existing connection. If not, the client will 401 establish a new connection and send the query over that connection. 403 Clients MAY discard their connection to the server before the idle 404 timeout expires. If they do that, they SHOULD close the connection 405 explicitly, using QUIC's CONNECTION_CLOSE mechanisms, and indicating 406 the Application reason "No Error". 408 Clients and servers MAY close the connection for a variety of other 409 reasons, indicated using QUIC's CONNECTION_CLOSE. Client and servers 410 that send packets over a connection discarded by their peer MAY 411 receive a stateless reset indication. If a connection fails, all 412 queries in progress over the connection MUST be considered failed, 413 and a Server Failure (SERVFAIL, [RFC1035]) SHOULD be notified to the 414 initiator of the transaction. 416 4.5. Connection Resume and 0-RTT 418 A stub resolver MAY take advantage of the connection resume 419 mechanisms supported by QUIC transport [I-D.ietf-quic-transport] and 420 QUIC TLS [I-D.ietf-quic-tls]. Stub resolvers SHOULD consider 421 potential privacy issues associated with session resume before 422 deciding to use this mechanism. These privacy issues are detailed in 423 Section 7.2. 425 When resuming a session, a stub resolver MAY take advantage of the 426 0-RTT mechanism supported by QUIC. The 0-RTT mechanism MUST NOT be 427 used to send data that is not "replayable" transactions. For 428 example, a stub resolver MAY transmit a Query as 0-RTT, but MUST NOT 429 transmit an Update. 431 4.6. Message Sizes 433 DoQ Queries and Responses are sent on QUIC streams, which in theory 434 can carry up to 2^62 bytes. However, DNS messages are restricted in 435 practice to a maximum size of 65535 bytes. This maximum size is 436 enforced by the use of a two-octet message length field in DNS over 437 TCP [RFC1035] and DNS over TLS [RFC7858], and by the definition of 438 the "application/dns-message" for DNS over HTTP [RFC8484]. DoQ 439 enforces the same restriction. 441 The maximum size of messages is controlled in QUIC by the transport 442 parameters: 444 o initial_max_stream_data_bidi_local: when set by the client, 445 specifies the amount of data that servers can send on a "response" 446 stream without waiting for a MAX_STREAM_DATA frame. 448 o initial_max_stream_data_bidi_remote: when set by the server, 449 specifies the amount of data that clients can send on a "query" 450 stream without waiting for a MAX_STREAM_DATA frame. 452 Clients and servers MUST set these two parameters to the value 65535. 453 If they receive a different value, they SHOULD close the QUIC 454 connection with an application error "Invalid Parameter". 456 The Extension Mechanisms for DNS (EDNS) [RFC6891] allow peers to 457 specify the UDP message size. This parameter is ignored by DoQ. DoQ 458 implementations always assume that the maximum message size is 65535 459 bytes. 461 5. Implementation Requirements 463 5.1. Authentication 465 For the stub to recursive resolver scenario, the authentication 466 requirements are the same as described in DoT [RFC7858] and "Usage 467 Profiles for DNS over TLS and DNS over DTLS" [RFC8310]. There is no 468 need to authenticate the client's identity in either scenario. 470 5.2. Fall Back to Other Protocols on Connection Failure 472 If the establishment of the DoQ connection fails, clients SHOULD 473 attempt to fall back to DoT and then potentially clear text, as 474 specified in DoT [RFC7858] and "Usage Profiles for DNS over TLS and 475 DNS over DTLS" [RFC8310], depending on their privacy profile. 477 DNS clients SHOULD remember server IP addresses that don't support 478 DoQ, including timeouts, connection refusals, and QUIC handshake 479 failures, and not request DoQ from them for a reasonable period (such 480 as one hour per server). DNS clients following an out-of-band key- 481 pinned privacy profile ([RFC7858]) MAY be more aggressive about 482 retrying DoQ connection failures. 484 5.3. Address Validation 486 Section 8 of the QUIC transport specification 487 [I-D.ietf-quic-transport] defines Address Validation procedures to 488 avoid servers being used in address amplification attacks. DoQ 489 implementations MUST conform to this specification, which limits the 490 worst case amplification to a factor 3. 492 DoQ implementations SHOULD consider configuring servers to use the 493 Address Validation using Retry Packets procedure defined in section 494 8.1.2 of the QUIC transport specification [I-D.ietf-quic-transport]). 495 This procedure imposes a 1-RTT delay for verifying the return 496 routability of the source address of a client, similar to the DNS 497 Cookies mechanism [RFC7873]. 499 DoQ implementations that configure Address Validation using Retry 500 Packets SHOULD implement the Address Validation for Future 501 Connections procedure defined in section 8.1.3 of the QUIC transport 502 specification [I-D.ietf-quic-transport]). This defines how servers 503 can send NEW TOKEN frames to clients after the client address is 504 validated, in order to avoid the 1-RTT penalty during subsequent 505 connections by the client from the same address. 507 5.4. DNS Message IDs 509 When sending queries over a QUIC connection, the DNS Message ID MUST 510 be set to zero. 512 5.5. Padding 514 There are mechanisms specified for padding individual DNS messages in 515 "The EDNS(0) Padding Option" [RFC7830] and for padding within QUIC 516 packets (see Section 8.6 of the QUIC transport specification 517 [I-D.ietf-quic-transport]). 519 Implementations SHOULD NOT use DNS options for padding individual DNS 520 messages, because QUIC transport MAY transmit multiple STREAM frames 521 containing separate DNS messages in a single QUIC packet. Instead, 522 implementations SHOULD use QUIC PADDING frames to align the packet 523 length to a small set of fixed sizes, aligned with the 524 recommendations of the "Padding Policies for Extension Mechanisms for 525 DNS (EDNS(0))" [RFC8467]. 527 5.6. Connection Handling 529 "DNS Transport over TCP - Implementation Requirements" [RFC7766] 530 provides updated guidance on DNS over TCP, some of which is 531 applicable to DoQ. This section attempts to specify which and how 532 those considerations apply to DoQ. 534 5.6.1. Connection Reuse 536 Historic implementations of DNS stub resolvers are known to open and 537 close TCP connections for each DNS query. To avoid excess QUIC 538 connections, each with a single query, clients SHOULD reuse a single 539 QUIC connection to the recursive resolver. 541 In order to achieve performance on par with UDP, DNS clients SHOULD 542 send their queries concurrently over the QUIC streams on a QUIC 543 connection. That is, when a DNS client sends multiple queries to a 544 server over a QUIC connection, it SHOULD NOT wait for an outstanding 545 reply before sending the next query. 547 5.6.2. Resource Management and Idle Timeout Values 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 similar to those specified for DNS over 552 TCP [RFC7766], in particular with regard to: 554 o Concurrent Connections (Section 6.2.2) 556 o Security Considerations (Section 10) 558 Failure to do so may lead to resource exhaustion and denial of 559 service. 561 Clients that want to maintain long duration DoQ connections SHOULD 562 use the idle timeout mechanisms defined in Section 10.2 of the QUIC 563 transport specification [I-D.ietf-quic-transport]. Clients and 564 servers MUST NOT send the edns-tcp-keepalive EDNS(0) Option [RFC7828] 565 in any messages sent on a DoQ connection (because it is specific to 566 the use of TCP/TLS as a transport). If any message sent on a DoQ 567 connection contains an edns-tcp-keepalive EDNS(0) Option, this is a 568 fatal error and the recipient of the defective message MUST forcibly 569 abort the connection immediately. 571 This document does not make specific recommendations for timeout 572 values on idle connections. Clients and servers should reuse and/or 573 close connections depending on the level of available resources. 574 Timeouts may be longer during periods of low activity and shorter 575 during periods of high activity. 577 Clients that are willing to use QUIC's 0-RTT mechanism can 578 reestablish connections and send transactions on the new connection 579 with minimal delay overhead. These clients MAY chose low values of 580 the idle timer. 582 5.7. Processing Queries in Parallel 584 As specified in Section 7 of "DNS Transport over TCP - Implementation 585 Requirements" [RFC7766], resolvers are RECOMMENDED to support the 586 preparing of responses in parallel and sending them out of order. In 587 DoQ, they do that by sending responses on their specific stream as 588 soon as possible, without waiting for availability of responses for 589 previously opened streams. 591 5.8. Flow Control Mechanisms 593 Servers and Clients manage flow control as specified in QUIC. 595 Servers MAY use the "maximum stream ID" option of the QUIC transport 596 to limit the number of streams opened by the client. This mechanism 597 will effectively limit the number of DNS queries that a client can 598 send on a single DoQ connection. 600 6. Security Considerations 602 The security considerations of DoQ should be comparable to those of 603 DoT [RFC7858]. 605 7. Privacy Considerations 607 DoQ is specifically designed to protect the DNS traffic between stub 608 and resolver from observations by third parties, and thus protect the 609 privacy of queries sent by the stub. However, the recursive resolver 610 has full visibility of the stub's traffic, and could be used as an 611 observation point, as discussed in the revision of "DNS Privacy 612 Considerations" [I-D.ietf-dprive-rfc7626-bis]. These considerations 613 do not differ between DoT and DoQ and are not discussed further here. 615 QUIC incorporates the mechanisms of TLS 1.3 [RFC8446] and this 616 enables QUIC transmission of "0-RTT" data. This can provide 617 interesting latency gains, but it raises two concerns: 619 1. Adversaries could replay the 0-RTT data and infer its content 620 from the behavior of the receiving server. 622 2. The 0-RTT mechanism relies on TLS resume, which can provide 623 linkability between successive client sessions. 625 These issues are developed in Section 7.1 and Section 7.2. 627 7.1. Privacy Issues With 0-RTT data 629 The 0-RTT data can be replayed by adversaries. That data may trigger 630 queries by a recursive resolver to authoritative resolvers. 631 Adversaries may be able to pick a time at which the recursive 632 resolver outgoing traffic is observable, and thus find out what name 633 was queried for in the 0-RTT data. 635 This risk is in fact a subset of the general problem of observing the 636 behavior of the recursive resolver discussed in "DNS Privacy 637 Considerations" [RFC7626]. The attack is partially mitigated by 638 reducing the observability of this traffic. However, the risk is 639 amplified for 0-RTT data, because the attacker might replay it at 640 chosen times, several times. 642 The recommendation for TLS 1.3 [RFC8446] is that the capability to 643 use 0-RTT data should be turned off by default, and only enabled if 644 the user clearly understands the associated risks. 646 QUESTION: Should 0-RTT only be used with Opportunistic profiles (i.e. 647 disabled by default for Strict only)? 649 7.2. Privacy Issues With Session Resume 651 The QUIC session resume mechanism reduces the cost of re-establishing 652 sessions and enables 0-RTT data. There is a linkability issue 653 associated with session resume, if the same resume token is used 654 several times, but this risk is mitigated by the mechanisms 655 incorporated in QUIC and in TLS 1.3. With these mechanisms, clients 656 and servers can cooperate to avoid linkability by third parties. 657 However, the server will always be able to link the resumed session 658 to the initial session. This creates a virtual long duration 659 session. The series of queries in that session can be used by the 660 server to identify the client. 662 Enabling the server to link client sessions through session resume is 663 probably not a large additional risk if the client's connectivity did 664 not change between the sessions, since the two sessions can probably 665 be correlated by comparing the IP addresses. On the other hand, if 666 the addresses did change, the client SHOULD consider whether the 667 linkability risk exceeds the performance benefits. This evaluation 668 will obviously depend on the level of trust between stub and 669 recursive. 671 7.3. Traffic Analysis 673 Even though QUIC packets are encrypted, adversaries can gain 674 information from observing packet lengths, in both queries and 675 responses, as well as packet timing. Many DNS requests are emitted 676 by web browsers. Loading a specific web page may require resolving 677 dozen of DNS names. If an application adopts a simple mapping of one 678 query or response per packet, or "one QUIC STREAM frame per packet", 679 then the succession of packet lengths may provide enough information 680 to identify the requested site. 682 Implementations SHOULD use the mechanisms defined in Section 5.5 to 683 mitigate this attack. 685 8. IANA Considerations 687 8.1. Registration of DoQ Identification String 689 This document creates a new registration for the identification of 690 DoQ in the "Application Layer Protocol Negotiation (ALPN) Protocol 691 IDs" registry [RFC7301]. 693 The "doq" string identifies DoQ: 695 Protocol: DoQ 697 Identification Sequence: 0x64 0x6F 0x71 ("doq") 699 Specification: This document 701 8.2. Reservation of Dedicated Port 703 IANA is required to add the following value to the "Service Name and 704 Transport Protocol Port Number Registry" in the System Range. The 705 registry for that range requires IETF Review or IESG Approval 706 {{?RFC6335], and such a review was requested using the early 707 allocation process {{?RFC7120] for the well-known UDP port in this 708 document. Since port 853 is reserved for 'DNS query-response 709 protocol run over TLS' consideration is requested for reserving port 710 TBD for 'DNS query-response 711 protocol run over QUIC'. 713 Service Name domain-s 714 Transport Protocol(s) TCP/UDP 715 Assignee IESG 716 Contact IETF Chair 717 Description DNS query-response protocol run over QUIC 718 Reference This document 720 8.2.1. Port number 784 for experimentations 722 *RFC Editor's Note:* Please remove this section prior to publication 723 of a final version of this document. 725 Early experiments MAY use port 784. This port is marked in the IANA 726 registry as unassigned. 728 9. Acknowledgements 730 This document liberally borrows text from the HTTP-3 specification 731 [I-D.ietf-quic-http] edited by Mike Bishop, and from the DoT 732 specification [RFC7858] authored by Zi Hu, Liang Zhu, John Heidemann, 733 Allison Mankin, Duane Wessels, and Paul Hoffman. 735 The privacy issue with 0-RTT data and session resume were analyzed by 736 Daniel Kahn Gillmor (DKG) in a message to the IETF "DPRIVE" working 737 group [DNS0RTT]. 739 Thanks to Tony Finch for an extensive review of the initial version 740 of this draft. 742 10. References 744 10.1. Normative References 746 [I-D.ietf-dnsop-terminology-ter] 747 Hoffman, P., "Terminology for DNS Transports and 748 Location", draft-ietf-dnsop-terminology-ter-02 (work in 749 progress), August 2020. 751 [I-D.ietf-quic-tls] 752 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 753 draft-ietf-quic-tls-31 (work in progress), September 2020. 755 [I-D.ietf-quic-transport] 756 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 757 and Secure Transport", draft-ietf-quic-transport-31 (work 758 in progress), September 2020. 760 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 761 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 762 . 764 [RFC1035] Mockapetris, P., "Domain names - implementation and 765 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 766 November 1987, . 768 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 769 for DNS (EDNS(0))", STD 75, RFC 6891, 770 DOI 10.17487/RFC6891, April 2013, . 773 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 774 "Transport Layer Security (TLS) Application-Layer Protocol 775 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 776 July 2014, . 778 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 779 D. Wessels, "DNS Transport over TCP - Implementation 780 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 781 . 783 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 784 and P. Hoffman, "Specification for DNS over Transport 785 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 786 2016, . 788 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 789 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 790 . 792 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 793 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 794 May 2017, . 796 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 797 for DNS over TLS and DNS over DTLS", RFC 8310, 798 DOI 10.17487/RFC8310, March 2018, . 801 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 802 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 803 . 805 10.2. Informative References 807 [DNS0RTT] Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG 808 mailing list, April 2016, . 811 [I-D.ietf-dprive-phase2-requirements] 812 Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS 813 Privacy Requirements for Exchanges between Recursive 814 Resolvers and Authoritative Servers", draft-ietf-dprive- 815 phase2-requirements-01 (work in progress), June 2020. 817 [I-D.ietf-dprive-rfc7626-bis] 818 Wicinski, T., "DNS Privacy Considerations", draft-ietf- 819 dprive-rfc7626-bis-07 (work in progress), October 2020. 821 [I-D.ietf-dprive-xfr-over-tls] 822 Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. 823 Mankin, "DNS Zone Transfer-over-TLS", draft-ietf-dprive- 824 xfr-over-tls-02 (work in progress), July 2020. 826 [I-D.ietf-quic-http] 827 Bishop, M., "Hypertext Transfer Protocol Version 3 828 (HTTP/3)", draft-ietf-quic-http-31 (work in progress), 829 September 2020. 831 [I-D.ietf-quic-recovery] 832 Iyengar, J. and I. Swett, "QUIC Loss Detection and 833 Congestion Control", draft-ietf-quic-recovery-31 (work in 834 progress), September 2020. 836 [RFC1885] Conta, A. and S. Deering, "Internet Control Message 837 Protocol (ICMPv6) for the Internet Protocol Version 6 838 (IPv6)", RFC 1885, DOI 10.17487/RFC1885, December 1995, 839 . 841 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 842 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 843 . 845 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 846 DOI 10.17487/RFC7626, August 2015, . 849 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 850 edns-tcp-keepalive EDNS0 Option", RFC 7828, 851 DOI 10.17487/RFC7828, April 2016, . 854 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 855 DOI 10.17487/RFC7830, May 2016, . 858 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 859 Transport Layer Security (DTLS)", RFC 8094, 860 DOI 10.17487/RFC8094, February 2017, . 863 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 864 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 865 . 867 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 868 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 869 October 2018, . 871 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 872 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 873 RFC 8490, DOI 10.17487/RFC8490, March 2019, 874 . 876 Authors' Addresses 878 Christian Huitema 879 Private Octopus Inc. 880 427 Golfcourse Rd 881 Friday Harbor WA 98250 882 U.S.A 884 Email: huitema@huitema.net 886 Allison Mankin 887 Salesforce 889 Email: amankin@salesforce.com 890 Sara Dickinson 891 Sinodun IT 892 Oxford Science Park 893 Oxford OX4 4GA 894 U.K. 896 Email: sara@sinodun.com