DNS over Dedicated QUIC Connections
RFC 9250
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
Erik Kline Yes
[S6.2; comment]
* Mobile clients might also remember DoQ connection success/failure to
given IPs on a per-{network,path,provisioning domain} basis.
Lars Eggert Yes
Section 5.5. , paragraph 4, comment: > The 0-RTT mechanism SHOULD NOT be used to send DNS requests that are > not "replayable" transactions. In this specification, only > transactions that have an OPCODE of QUERY or NOTIFY are considered > replayable and MAY be sent in 0-RTT data. See Appendix A for a > detailed discussion of why NOTIFY is included here. I think the "SHOULD NOT" should become a "MUST NOT", given that servers don't execute it anyway. Also, the "and MAY be sent in 0-RTT data" bit isn't using the RFC2119 terms correctly. Suggest to remove it and replace it with "other OPCODEs MUST NOT be sent in 0-RTT data". Thanks to Stewart Bryant for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/knoZG7fEYMwRxN7B5Q5o8YhPcbw). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1. , paragraph 7, nit: - 3. Provide a transport that is not constrained by path MTU - ^ ^ - ----- ---- - limitations on the size of DNS responses it can send. - ^ --- + 3. Provide a transport that does not impose path MTU + ^^^ ^^^ + limitations on the size of DNS messages it can send. + ^ ++ Section 5.3.3. , paragraph 6, nit: - expected (e.g. multiple responses to a query for an A record) + expected (e.g., multiple responses to a query for an A record) + + Section 5.5. , paragraph 4, nit: - Servers MUST NOT execute non replayable transactions received in - ^ + Servers MUST NOT execute non-replayable transactions received in + ^ Section 9.5. , paragraph 2, nit: - dozen of DNS names. If an application adopts a simple mapping of one + dozens of DNS names. If an application adopts a simple mapping of one + + Section 1. , paragraph 16, nit: > BE REMOVED BEFORE PUBLICATION)The Github repository for this document is at > ^^^^^^ The official name of this software platform is spelled with a capital "H". Section 5.2.1. , paragraph 2, nit: > : The DoQ implementation encountered an protocol error and is forcibly aborti > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". Section 5.3. , paragraph 5, nit: > rcumstances servers might very well chose to send different error codes. Not > ^^^^^ The modal verb "might" requires the verb's base form. Section 6.5.1. , paragraph 2, nit: > ssion create privacy risks detailed in detailed in Section 9.2 and Section 9 > ^^^^^^^^^^^^^^^^^^^^^^^ This phrase is duplicated. You should probably use "detailed in" only once. Section 6.5.2. , paragraph 5, nit: > tickets with a sufficiently long life time (e.g., 6 hours), so that clients > ^^^^^^^^^ This noun is normally spelled as one word.
Roman Danyliw Yes
Éric Vyncke Yes
Alvaro Retana No Objection
§5.3.3 lists some protocol error scenarios that are considered fatal. If a peer encounters such an error condition it is considered a fatal error. It SHOULD forcibly abort the connection using QUIC's CONNECTION_CLOSE mechanism, and SHOULD use the DoQ error code DOQ_PROTOCOL_ERROR. When is it ok not to abort the connection? Why is aborting the connection recommended and not required if the errors are considered fatal?
Francesca Palombini No Objection
Thank you for the work on this document, I only have two comments below. Francesca 1. ----- 443 is less likely to be blocked than other ports. Several mechanisms for stubs to discover recursives offering encrypted transports, including the use of custom ports, are the subject of ongoing work. and For the recursive resolver to authoritative nameserver scenario, authentication requirements are unspecified at the time of writing and are the subject on ongoing work in the DPRIVE WG. FP: Are there (informative) references you can point the reader to? 2. ---- If a peer encounters such an error condition it is considered a fatal error. It SHOULD forcibly abort the connection using QUIC's CONNECTION_CLOSE mechanism, and SHOULD use the DoQ error code DOQ_PROTOCOL_ERROR. FP: Just seeing now that Alvaro has the same comment here - it would make sense to state why the first SHOULD is not a MUST. What is the exception where it would make sense that the peer does not abort the connection? Or is it the CONNECTION_CLOSE mechanism that can be skipped in some cases, so the "SHOULD" apply only to that mechanism and not to the abort? Some more text here would be useful.
John Scudder No Objection
Thanks for this, I found it clear and easy to read. I have just a couple comments.
1. In §5.2, there is
Servers MAY defer processing of a query until the STREAM FIN has been
indicated on the stream selected by the client. Servers and clients
MAY monitor the number of "dangling" streams for which the expected
queries or responses have been received but not the STREAM FIN.
Implementations MAY impose a limit on the number of such dangling
streams. If limits are encountered, implementations MAY close the
connection.
Wouldn’t a stream be dangling even if the expected queries and responses hadn’t been received? I.e., isn’t the thing that makes a stream “dangling” simply the lack of a STREAM FIN?
2. In §5.4,
Client and servers
that send packets over a connection discarded by their peer MAY
receive a stateless reset indication.
This seems like a misuse of the RFC 2119 MAY. Do you mean "may" or better still, "might" or "could"? If you really mean the 2119 keyword, then a rewrite seems to be in order to put this in terms of the other party being permitted to send the reset.
Martin Duke No Objection
Thanks for this draft! It was very easy to read. (4.3) says: "Using QUIC might allow a protocol to disguise its purpose from devices on the network path using encryption and traffic analysis resistance techniques like padding. This specification does not include any measures that are designed to avoid such classification." but then Sec 6.4 has a detailed, normative discussion of how to use padding to avoid classification. I suggest you delete or edit the bit in 4.3. (5.3.1) Clients are allowed to send STOP_SENDING and servers are allowed to send RESET_STREAM. Servers sending STOP_SENDING break the connection. Given the prescriptiveness of these rules, it's odd that you don't address clients sending RESET_STREAM. IMO this should be allowed, but either way it should be specified. (6.5.4) and (9.4) I hesitate to write this, as Christian is as well aware as anyone, but IMO QUIC address migration is not quite as privacy-destroying as this draft suggests. RFC9000 has a number of normative requirements to reduce linkability, and work is ongoing to reduce it further. Granted, no anti-linkability mitigation is perfect, and if this is a primary goal of DoQ it's OK to discourage migration as you've done here.
Murray Kucherawy No Objection
Now THAT is a well done shepherd writeup. Thanks for this work, which was an interesting read. It's great to see this so quickly on the heels of QUIC itself. Just a couple of BCP 14 things to point out. In Section 5.4, we have this: Clients SHOULD monitor the idle time incurred on their connection to the server, defined by the time spent since the last packet from the server has been received. When a client prepares to send a new DNS query to the server, it will check whether the idle time is sufficiently lower than the idle timer. If it is, the client will send the DNS query over the existing connection. If not, the client will establish a new connection and send the query over that connection. There's a blanket SHOULD, followed by two "will"s. I read those as normative requirements, even though they don't use BCP 14 language. But that means they conflict with the SHOULD. IMHO, this needs to be resolved. In Section 5.5: Clients SHOULD consider potential privacy issues associated with session resumption before deciding to use this mechanism. [...] I find "SHOULD consider" to be far too vague for this to be meaningful. If I've thought about it, have I met my burden here? Thank you for including Section 7. And now, some nits. Abstract: * "... similar properties to that provided by ..." -- s/that/those/ Section 1: * "DNS over QUIC is referred here as ..." -- s/referred/referenced/ or s/referred/referred to/ Section 5.2: * The second-last paragraph is missing a closing parenthesis.
Robert Wilton No Objection
Hi, Thanks for this doc. It looks like DNS and QUIC could be a good fit. Just a few minor comments/questions. In QUIC, sending STOP_SENDING requests that a peer cease transmission on a stream. If a DoQ client wishes to cancel an outstanding request, it MUST issue a QUIC STOP_SENDING with error code DOQ_REQUEST_CANCELLED. This may be sent at any time but will be ignored if the server response has already been acknowledged. The corresponding DNS transaction MUST be abandoned. I presume that there is no requirement that the DNS transaction be immediately abandoned. E.g., if a server already has a reply queued for sending, then it is still reasonable to send that response? Because new error codes can be defined without negotiation, use of an error code in an unexpected context or receipt of an unknown error code MUST be treated as equivalent to DOQ_NO_ERROR. I find DOQ_NO_ERROR to be a strange name for an error code because I would naturally assume that DOQ_NO_ERROR is equivalent to "success", but that doesn't seem to be the intention here. In particular, I find it strange to treat an unknown error equivalently to DOQ_NO_ERROR. I'm not saying that the behaviour is wrong, only that the naming is slightly strange/confusing. In theory, padding at the QUIC level could result in better performance for the equivalent protection As a nit, I didn't find "QUIC level" to be particularly clear, and hence I was wondering whether this could be clarified. E.g., is this at the QUIC protocol level, or QUIC packet level. 10.4. DNS over QUIC Error Codes Registry Registrations in this registry MUST include the following fields: This lists various fields that MUST be included, but doesn't specify values for the initially assigned values in the table. Regards, Rob
Zaheduzzaman Sarker No Objection
Thanks a lot for working on this specification. Thanks to Brian Trammell for the TSVART review.
I have following comments and I think addressing them will improve this documentation-
* Section 5.3.3 - should also list the protocol error case related to session resumption and 0-RTT, and put a reference to section 5.5 for further details.
* Section 5.2 says -
"Implementations MAY impose a limit on the number of such dangling streams. If limits are encountered, implementations MAY close the connection."
However, I have not notices any indication of how this limits can be set. I would be great if we can say how the implementer can enforce the normative "MAY".
(Benjamin Kaduk; former steering group member) (was Discuss) Yes
Moving my previous Discuss point to the Comment section: Thank you for confirming that the server is permitted to disable 0-RTT entirely. Let's try to work out a way to add some text that makes this more explicit. [previous COMMENT position retained below, unchanged] Thanks to Phillip Hallam-Baker for the secdir review. I did want to reiterate one of his comments, regarding the potential for harmful interaction between use of DoQ (or really, any encrypted DNS transport) and captive portals. While this would accordingly have been best placed in something generic to DNS privacy mechanisms, such as RFC 9076 or RFC 8932, I think there might still be room to mention it here. I could attempt to craft some text, if there is interest. I made a pull request with some editorial suggestions at https://github.com/huitema/dnsoquic/pull/154 Section 1 The specific non-goals of this document are: [...] 2. No attempt to support server-initiated transactions, which are used only in DNS Stateful Operations (DSO) [RFC8490]. RFC 8490 is a proposed standard, so excluding it maybe is a bit in conflict with claiming that this is a "general-purpose transport for DNS", absent some other argument that DSO is a special-purpose tool. Section 5.1.2 DoQ connections MUST NOT use UDP port 53. This recommendation against use of port 53 for DoQ is to avoid confusion between DoQ and the use of DNS over UDP [RFC1035]. Just to clarify: this prohibition is intended to apply even if there would otherwise be mutual agreement to use port 53? Section 5.2 DNS traffic follows a simple pattern in which the client sends a query, and the server provides one or more responses (multiple responses can occur in zone transfers). Is this true even for DSO server-initiated transactions? The client MUST select the next available client-initiated bidirectional stream for each subsequent query on a QUIC connection, in conformance with the QUIC transport specification [RFC9000]. Just to note: RFC 9000 does not require the client to *use* the "next available" stream, instead saying that "a stream ID that is used out of order results in all streams of that type with lower- numbered stream IDs also being opened". So this "MUST select the next available" is a new requirement for DoQ, and it's not entirely clear to me that it's required for interop (though it is more efficient than any alternatives). Section 5.2.1 This has implications for proxying DoQ message to and from other transports. For example, proxies may have to manage the fact that DoQ can support a larger number of outstanding queries on a single connection than e.g., DNS over TCP because DoQ is not limited by the Message ID space. This issue already exists for DoH, where a Message ID of 0 is recommended. I'm not sure how often this motivating text is relevant. The ID field seems to be 16 bits, thus enabling 65k outstanding queries on a single connection -- how often is there a need to have that many queries outstanding at once? It looks like the motivation presented in RFC 8484 for setting the ID to zero is to improve caching, as otherwise queries identical at the DNS level would be cached as separate requests by HTTP. I agree, of course, that the ID field is redundant with the QUIC stream ID and that it should be set to zero, I am just not sure if the number of outstanding queries is a relevant motivation for doing so. (It also looks like RFC 8484 refers to this value as the "DNS ID" rather than "Message ID". I guess our options for consistent terminology are somewhat limited, though.) Section 5.3 The following error codes are defined for use when abruptly terminating streams, aborting reading of streams, or immediately closing connections: Should we say that these are what QUIC calls "application error code"s? (Subsequent occurrences of the phrase "error code" might be modified to "application error code" as well.) Section 5.3.2 set to DOQ_INTERNAL_ERROR. [...] Is there any further guidance to give on when a DNS SERVFAIL response vs QUIC RESET_STREAM is preferred (or is the guidance really always to issue RESET_STREAM)? Section 5.3.3 It is noted that the restrictions on use of the above EDNS(0) options has implications for proxying message from TCP/DoT/DoH over DoQ. Was it already rejeted to spend a sentence mentioning that such proxying would involve translating the messages per the needs of the different protocols on the different connections? Section 5.5 Servers MUST NOT execute non replayable transactions received in 0-RTT data. Servers MUST adopt one of the following behaviors: I think we should clarify whether "execute" means "take any action in response to" or just "send a response message for". (I think it needs to be the former.) Section 6.4 Implementations MUST protect against the traffic analysis attacks described in Section 9.5 by the judicious injection of padding. This I think this is already overtaken by events, but a MUST-level requirement seems overbearing here. My understanding is that providing complete protection against these types of attack is still an open research question.... could be done either by padding individual DNS messages using the EDNS(0) Padding Option [RFC7830] or by padding QUIC packets (see Section 8.6 of [RFC9000], the QUIC transport specification. There is no Section 8.6 in RFC 9000. Section 6.5.2 Clients that want to maintain long duration DoQ connections SHOULD use the idle timeout mechanisms defined in Section 10.1 of [RFC9000], the QUIC transport specification. Clients and servers MUST NOT send the edns-tcp-keepalive EDNS(0) Option [RFC7828] in any messages sent on a DoQ connection (because it is specific to the use of TCP/TLS as a transport). Should we make some statement (analogous to what RFC 7828 does) that if such an option is received it MUST be ignored? In the absence of such guidance I can imagine implementors feeling a need to enforce the "MUST NOT send" on the receiving end. Section 6.7 [RFC9103] specifies zone transfer over TLS (XoT) and includes updates to [RFC1995] (IXFR), [RFC5936] (AXFR) and [RFC7766]. [...] I note that there is currently no "Updates:" header to indicate this relationship. * DoQ implementations SHOULD - use the same QUIC connection for both AXFR and IXFR requests to the same primary - pipeline such requests (if they pipeline XFR requests in general) and MAY intermingle them - send the response(s) for each request as soon as they are available i.e. responses MAY be sent intermingled Given the "SHOULD use the same QUIC connection", what does MAY-level guidance to "intermingle such requests" mean, in a QUIC context? Each DoQ request is on a separate QUIC stream, so I do not see any opportunity for intermingling other than by virtue of being in the same QUIC connection, which is already a SHOULD. This is in contrast to a TCP or TLS situation, where there is only a single data stream and intermingling has some natural meaning (or meanings, for the response case specifically, where it might apply to overall responses (composed of multiple response messages) or individual response messages). Section 8 The discussion in §6.5.2 about resource management could be security relevant at times, if we wanted to backreference it. The security considerations of DoQ should be comparable to those of DoT [RFC7858]. DoT as specified in [RFC7858] only addresses the stub The security considerations section of RFC 7858 includes a MUST-level requirement to adhere to the recommendations of BCP 195. Does such a MUST-level requirement apply to DoQ as well? (I note that BCP 195 is currently listed as only an informative reference, which would need to change if a MUST-level requirement was added.) to recursive resolver scenario, but the considerations about person- in-the-middle attacks, middleboxes and caching of data from clear text connections also apply for DoQ to the resolver to authoritative server scenario. [...] RFC 7858 also lists a fourth consideration, traffic analysis or side-channel leaks. Do we want to forward-reference §9.5 for completeness (or even take the secdir reviewer's suggestion of coalescing the privacy considerations into the security considerations section as confidentiality considerations)? Section 9.1 The prevention on allowing replayable transactions in 0-RTT data expressed in Section 5.5 blocks the most obvious risks of replay Is the parity of negations correct here ("prevention on allowing")? I see §5.5 prohibiting execution of non-replayable transactions in 0-RTT data, i.e., allowing replayable ones. Section 10.4 Provisional reservations share the range of values larger than 0x3f with some permanent registrations. This is by design, to enable conversion of provisional registrations into permanent registrations without requiring changes in deployed systems. (This design is aligned with the principles set in Section 22 of [RFC9000].) Do we want to specifically call out the guidance on selecting specific codepoints from §22.1.2 of RFC 9000? (Or is it seen as not applicable here?) Section 12.1 We currently only specifically reference RFC 6891 in one place, to mention that its provision for specifying maximum UDP message size is not relevant for DoQ. However, since we do define and require (in some cases) use of a new "Too Early" EDNS(0) error code, it seems that the solution should be to reference it from more places, rather than to demote it to an informative reference. Similarly, we only reference RFC 8914 in the IANA considerations where we allocate the codepoint, and would likely benefit from sprinkling an additional reference or two in the main body of the text. RFC 7828, on the other hand, seems to only be mentioned to say that you MUST NOT use it, which would probably be fine as an informative reference. RFC 7873 is referenced for "similar to the DNS Cookies mechanism", which also sounds solely informative. [I-D.ietf-dnsop-rfc8499bis] Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03, It's kind of surprising to see DoQ electing to take a normative dependency on this draft that is not even in WGLC yet. Wouldn't that risk incurring substantial (unbounded) delays? Section 12.2 A SHOULD-level requirement to implement the anti-replay mechanisms from RFC 8446 seems to promote it to normative status, per https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
(Martin Vigoureux; former steering group member) No Objection