From [email protected]: I wonder if you can consider making this change in dprive-dnsoquic I-D:

OLD:

   By default, a DNS server that supports DoQ MUST listen for and accept
   QUIC connections on the dedicated UDP port TBD (number to be defined
   in Section 8), unless it has mutual agreement with its clients to use
   a port other than TBD for DoQ.  In order to use a port other than
   TBD, both clients and servers would need a configuration option in
   their software.

 

NEW:

   By default, a DNS server that supports DoQ MUST listen for and accept
   QUIC connections on the dedicated UDP port TBD (number to be defined
   in Section 8), unless it has mutual agreement with its clients to use
   a port other than TBD for DoQ (e.g., [I-D.btw-add-ipsecme-ike]).
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   In order to use a port other than TBD, both clients and servers
   would need a configuration option in their software.

From Tom Pusateri:

In 6.6.3, it would be nice to recommend Session Signaling TLVs over equivalent EDNS(0) options for QUIC
connections since you are recommending keeping the connection open and reusing it.

We already have a mention of session signaling in that session (now 5.6.3. Idle Timeouts). But we may need some better text.

Section 9.2. (Privacy Issues With Session Resumption) goes on at great lengths about the risks of linkability through session resumption tokens. This is fine, but the same risks exist by virtue of connection reuse, something the specification firmly recommends. The draft should acknowledge this, maybe changing this section to be entitled "Linkability through Connection Reuse and Session Resumption".

Clients MAY discard their connection to the server before the idle timeout expires. If they do that, they SHOULD close the connection explicitly, using QUIC's CONNECTION_CLOSE mechanism, and use the DoQ error code DOQ_NO_ERROR.

This seems unnecessary. The server never initiates communication toward a client, so failing to send CONNECTION_CLOSE does not result in any loss of state that a server might care about. I would remove this recommendation (and add it back if you ever do DSO).

As shown in this thread, being too picky with transport parameters leads to interop issues;

J’ai relaxé le test des TP dans Quicdoq, et aussi fixé le RD bit -- private-octopus/quicdoq#23.

Normalement, les tests devraient marcher maintenant.

J'aimerai plus de détails pour l'intégration avec unbound -- pour déployer ça sur mon serveur "test.privateoctopus.com".

-- Christian Huitema

On 11/27/2020 8:19 AM, Christian Huitema wrote:

On 11/27/2020 6:57 AM, Stephane Bortzmeyer wrote:

Bonjour,

J'essaie de faire communiquer quicdoq et aoiquic. En HTTP/3, pas de
problèmes, picoquic et aoiquic peuvent échanger.

En DoQ, ça ne va plus. Un serveur quicdoq et un client aoiquic
n'interopèrent pas.

Le serveur quicdoq voit :

% ./quicdoq_app -p 7844 -d 192.168.2.254 -l '-'
Starting the quicdoq server on port 7844, back end UDP server 192.168.2.254
75e4bdaece6ddeec: Receiving 1280 bytes from [0:0:0:0:0:0:0:1]:54930 at T=0.000000 (5b517bdb3d063)
75e4bdaece6ddeec: Receiving packet type: 2 (initial), S0, Q1, Version ff000020,
75e4bdaece6ddeec: <75e4bdaece6ddeec>, , Seq: 0, pl: 1254
75e4bdaece6ddeec: Token length: 0
75e4bdaece6ddeec: Decrypted 1236 bytes
75e4bdaece6ddeec: Crypto HS frame, offset 0, length 360: 0100016403032c3c...
75e4bdaece6ddeec: padding, 872 bytes

75e4bdaece6ddeec: ALPN[0] matches default alpn (doq-i00)
75e4bdaece6ddeec: Received ALPN list (1): doq-i00
75e4bdaece6ddeec: Received transport parameter TLS extension (63 bytes):
75e4bdaece6ddeec: Extension list (63 bytes):
75e4bdaece6ddeec: Extension type: 1 (idle_timeout), length 4, 8000ea60
75e4bdaece6ddeec: Extension type: 4 (initial_max_data), length 4, 80100000
75e4bdaece6ddeec: Extension type: 5 (max_stream_data_bidi_local), length 4, 80100000
75e4bdaece6ddeec: Extension type: 6 (max_stream_data_bidi_remote), length 4, 80100000
75e4bdaece6ddeec: Extension type: 7 (max_stream_data_uni), length 4, 80100000
75e4bdaece6ddeec: Extension type: 8 (max_streams_bidi), length 2, 4080
75e4bdaece6ddeec: Extension type: 9 (max_streams_uni), length 2, 4080
75e4bdaece6ddeec: Extension type: 10 (ack_delay_exponent), length 1, 03
75e4bdaece6ddeec: Extension type: 11 (max_ack_delay), length 1, 19
75e4bdaece6ddeec: Extension type: 14 (active_connection_id_limit), length 1, 08
75e4bdaece6ddeec: Extension type: 15 (hcid), length 8, ca2fc575e6c8aa0e
75e4bdaece6ddeec: Extension type: 32 (max_datagram_frame_size), length 4, 80010000
75e4bdaece6ddeec: Sending transport parameter TLS extension (77 bytes):
75e4bdaece6ddeec: Extension list (77 bytes):
75e4bdaece6ddeec: Extension type: 5 (max_stream_data_bidi_local), length 1, 00
75e4bdaece6ddeec: Extension type: 4 (initial_max_data), length 4, 80010000
75e4bdaece6ddeec: Extension type: 8 (max_streams_bidi), length 2, 4041
75e4bdaece6ddeec: Extension type: 1 (idle_timeout), length 4, 80004e20
75e4bdaece6ddeec: Extension type: 3 (max_packet_size), length 2, 44d0
75e4bdaece6ddeec: Extension type: 6 (max_stream_data_bidi_remote), length 4, 8000ffff
75e4bdaece6ddeec: Extension type: 14 (active_connection_id_limit), length 1, 03
75e4bdaece6ddeec: Extension type: 11 (max_ack_delay), length 1, 0a
75e4bdaece6ddeec: Extension type: 15 (hcid), length 8, c02eeb19e95d19e7
75e4bdaece6ddeec: Extension type: 0 (ocid), length 8, 75e4bdaece6ddeec
75e4bdaece6ddeec: Extension type: 2 (stateless_reset_token), length 16, 7592582700c81b8b8fca52e8442b405f
75e4bdaece6ddeec: Extension type: 32 (max_datagram_frame_size), length 2, 4600
75e4bdaece6ddeec: Sending packet type: 2 (initial), S0, Q1, Version ff000020,
75e4bdaece6ddeec: , , Seq: 0, pl: 153
75e4bdaece6ddeec: Token length: 0
75e4bdaece6ddeec: Prepared 133 bytes
75e4bdaece6ddeec: ACK (nb=0), 0
75e4bdaece6ddeec: Crypto HS frame, offset 0, length 123: 020000770303cc39...

75e4bdaece6ddeec: Sending packet type: 4 (handshake), S0, Q1, Version ff000020,
75e4bdaece6ddeec: , , Seq: 0, pl: 1028
75e4bdaece6ddeec: Prepared 1008 bytes
75e4bdaece6ddeec: Crypto HS frame, offset 0, length 1004: 0800006500630000...

75e4bdaece6ddeec: Sending 1232 bytes to [0:0:0:0:0:0:0:1]:54930 at T=0.001783 (5b517bdb3d75a)
75e4bdaece6ddeec: Quicdoq: Invalid transport parameters

The spec says, section 4.6:

The maximum size of messages is controlled in QUIC by the transport parameters:

o initial_max_stream_data_bidi_local: when set by the client,
specifies the amount of data that servers can send on a "response"
stream without waiting for a MAX_STREAM_DATA frame.

o initial_max_stream_data_bidi_remote: when set by the server,
specifies the amount of data that clients can send on a "query"
stream without waiting for a MAX_STREAM_DATA frame.

Clients and servers MUST set these two parameters to the value 65535.
If they receive a different value, they SHOULD close the QUIC
connection with an application error "Invalid Parameter".

The client (aioquic) sent:

75e4bdaece6ddeec: Extension type: 5 (max_stream_data_bidi_local), length 4, 80100000
75e4bdaece6ddeec: Extension type: 6 (max_stream_data_bidi_remote), length 4, 80100000

This is technically a violation of the spec -- max size 0x100000 instead of 0xFFFF.

The server sent:

75e4bdaece6ddeec: Extension type: 6 (max_stream_data_bidi_remote), length 4, 8000ffff

Which is the expected value. But the server does not set "max_stream_data_bidi_local", because it does not expect to create streams.

75e4bdaece6ddeec: Sending packet type: 4 (handshake), S0, Q1, Version ff000020,
75e4bdaece6ddeec: , , Seq: 1, pl: 270
75e4bdaece6ddeec: Prepared 250 bytes
75e4bdaece6ddeec: Crypto HS frame, offset 1004, length 245: 872aca323d89c6fc...

75e4bdaece6ddeec: Sending packet type: 6 (1rtt protected), S0, Q1,
75e4bdaece6ddeec: , Seq: 0 (0), Phi: 0,
75e4bdaece6ddeec: Prepared 3 bytes
75e4bdaece6ddeec: application_close, Error 0x0000, Reason length 0

The reason code should be DOQ_TRANSPORT_PARAMETER_ERROR (0x02)! This looks like a bug in QuicDoq

75e4bdaece6ddeec: Sending 324 bytes to [0:0:0:0:0:0:0:1]:54930 at T=0.001892 (5b517bdb3d7c7)
75e4bdaece6ddeec: Receiving 99 bytes from [0:0:0:0:0:0:0:1]:54930 at T=0.004501 (5b517bdb3e1f8)
75e4bdaece6ddeec: Receiving packet type: 2 (initial), S0, Q1, Version ff000020,
75e4bdaece6ddeec: , , Seq: 0, pl: 24
75e4bdaece6ddeec: Token length: 0
75e4bdaece6ddeec: Header or encryption error: 408.

75e4bdaece6ddeec: Closed. Retrans= 0, spurious= 0, max sp gap = 0, max sp delay = 0, dg-coal: 1.000000

Et le client aoiquic voit :

% python3 ./doq_client.py --port 7844 -v --insecure --query www.bortzmeyer.org --dns_type AAAA
2020-11-27 14:47:35,098 DEBUG client No session ticket defined...
2020-11-27 14:47:35,098 DEBUG asyncio Using selector: EpollSelector
2020-11-27 14:47:35,098 DEBUG client Connecting to localhost:7844
2020-11-27 14:47:35,106 DEBUG quic [75e4bdaece6ddeec] TLS State.CLIENT_HANDSHAKE_START -> State.CLIENT_EXPECT_SERVER_HELLO
2020-11-27 14:47:35,108 DEBUG quic [75e4bdaece6ddeec] QuicConnectionState.FIRSTFLIGHT -> QuicConnectionState.CONNECTED
2020-11-27 14:47:35,109 DEBUG quic [75e4bdaece6ddeec] TLS State.CLIENT_EXPECT_SERVER_HELLO -> State.CLIENT_EXPECT_ENCRYPTED_EXTENSIONS
2020-11-27 14:47:35,110 DEBUG quic [75e4bdaece6ddeec] TLS State.CLIENT_EXPECT_ENCRYPTED_EXTENSIONS -> State.CLIENT_EXPECT_CERTIFICATE_REQUEST_OR_CERTIFICATE
2020-11-27 14:47:35,110 DEBUG quic [75e4bdaece6ddeec] TLS State.CLIENT_EXPECT_CERTIFICATE_REQUEST_OR_CERTIFICATE -> State.CLIENT_EXPECT_CERTIFICATE_VERIFY
2020-11-27 14:47:35,110 DEBUG quic [75e4bdaece6ddeec] Discarding epoch Epoch.INITIAL
2020-11-27 14:47:35,111 DEBUG quic [75e4bdaece6ddeec] TLS State.CLIENT_EXPECT_CERTIFICATE_VERIFY -> State.CLIENT_EXPECT_FINISHED
2020-11-27 14:47:35,112 DEBUG quic [75e4bdaece6ddeec] TLS State.CLIENT_EXPECT_FINISHED -> State.CLIENT_POST_HANDSHAKE
2020-11-27 14:47:35,112 INFO quic [75e4bdaece6ddeec] ALPN negotiated protocol doq-i00
2020-11-27 14:47:35,112 INFO quic [75e4bdaece6ddeec] Connection close code 0x0, reason
2020-11-27 14:47:35,113 DEBUG quic [75e4bdaece6ddeec] QuicConnectionState.CONNECTED -> QuicConnectionState.DRAINING
2020-11-27 14:47:35,113 DEBUG client Sending DNS query www.bortzmeyer.org/AAAA
2020-11-27 14:47:35,113 DEBUG client Stream ID: 0
2020-11-27 14:47:35,161 DEBUG quic [75e4bdaece6ddeec] Discarding epoch Epoch.HANDSHAKE
2020-11-27 14:47:35,161 DEBUG quic [75e4bdaece6ddeec] Discarding epoch Epoch.ONE_RTT
2020-11-27 14:47:35,162 DEBUG quic [75e4bdaece6ddeec] QuicConnectionState.DRAINING -> QuicConnectionState.TERMINATED

Ce qui m'inquiète, c'est le "application_close, Error 0x0000, Reason
length 0" côté serveur. Le serveur décide de fermer mais pourquoi ?

Une idée ?

Voir ci-dessus. Deux solutions possibles:

1. Corriger l’implémentation AIOQUIC

2. Changer la spécification.

Je penche vers "changer la spec" pour deux raisons. La première est que cette restriction n'affecte que les performances, puisque les implémentations peuvent toujours renégocier le paramètre en cours de connexion s'il est trop petit. La deuxième est que le stack QUIC est souvent commun a plusieurs protocoles, par exemple DoQ et H3, et qu'on peut envisager des implémentations qui négocient l'ALPN durant la connection, et donc qui ne peuvent pas utiliser des paramètres spécifiques par application.

Mais si on ne spécifie pas la valeur des messages là, on devra discuter que faire si serveur ou client envoient des messages trop long, plus de 65635 octets.

-- Christian Huitema

See the connection termination discussion in QUIC. We need to ensure that as much as possible, client and server have the same assessment of a session state. This implies:

• If we are going to close connection on idle timer, have the value of idle timer communicated by
  client to server.

• If the server announced some timer and reneges on that, need to issue a public reset or something
  equivalent.

• Study the interaction with NAT. For example, if a transaction is ongoing, send some kind of keep alive.

The spec mentions a number of possible errors:

• Transaction ID not set to 0
• Query or response larger than 64K-1
• Incorrect transport parameters.

There should be either a generic "protocol violation" code for all these errors, or maybe specific code for each error.

An editorial suggestion: when referring to RFCs, can you please make it
clear what the reference is about (e.g. the subject of the RFC or name of
protocol) in the paragraph containing the reference, so that readers
can understand the paragraph without having to bounce back and forth to
the references section.

Section 4.3 talks about not deliberately avoiding the notice of middleboxes. This is fine, but it could use mention of ECH and what that might mean. Specifically, you might want to say something like:

DoQ neither mandate nor prohibits the use of the TLS Encrypt Client Hello (ECH) [REF] for hiding the value of the server name [rfc6066] or application protocol choice [rfc7301]. Deployments that use ECH to protect this information will be able to hide this information from middleboxes; deployments that do not use ECH will reveal this to middleboxes.

I don't think that it's worth going down the rabbit hole of what SNI value might be chosen or that SNI might not be used that often. That discussion belongs elsewhere.

Think again if we need to anything specific relating to XFR to remove any ambiguities between use of this for zone transfer and XoT.

From Martin J. Dürst [email protected]:

Just a very small comment on the title:

If this document's title needs to start with "Specification of", then I guess almost all IDs and RFCs would have to start with "Specification of". So I suggest leaving it out. "DNS over Dedicated QUIC Connections" should do the job.

STOP_SENDING would seem to be useful for this. But you will need an application error code at the QUIC level for that.

Section 9.1 (Privacy Issues With 0-RTT data) talks about attackers being able to replay 0-RTT, but does not acknowledge the mandatory anti-replay techniques in RFC 8446. This ends up being misleading.

For example:

However, the risk is amplified for 0-RTT data, because the attacker might replay it at chosen times, several times.

This is not true. If the time-based anti-replay techniques are deployed (which are mandatory and easy to implement), then an attacker cannot choose when to replay data. They are only able to replay within a narrow window, which is only wide enough to account for variations in clock skew and network transmission. This can be a fairly tight window depending on how willing you might be to reject 0-RTT if there is packet loss or relative clock drift.

Need more discussion, obviously, but here is a first text:

Even though QUIC packets are encrypted, adversaries can gain information from observing packet lengths, in both queries and responses, as well as packet timing. Many DNS requests are emitted by web browsers. Loading a specific web page may require resolving dozen of DNS names. If an application adopts a simple mapping of one query or response per packet, or "one QUIC STREAM frame per packet", then the succession of packet lengths may provide enough information to identify the requested site.

Implementations of DNS over QUIC SHOULD mitigate the packet length observation attacks. It is RECOMMENDED to transmit a variable number of STREAM frames in a single packet, and to use the padding options to align the packet length to a small set of fixed sizes.

On 3/6/2020 6:12 AM, Tony Finch wrote:

Section 4.3 (idle timeouts): it's clearly better to use QUIC's facilities
for this, but there could potentially be a conflict with DNS stateful
timeouts (RFC8490) so maybe there needs to be a bit more discussion about
how to resolve disagreements between two protocol layers.

Should the draft specify transport parameters? See this part of the transport draft:

Application Layer Protocol Negotiation (ALPN; see [ALPN]) allows clients to offer multiple application protocols during connection establishment. The transport parameters that a client includes during the handshake apply to all application protocols that the lient offers. Application protocols can recommend values for transport parameters, such as the initial flow control limits. However, application protocols that set constraints on values for transport parameters could make it impossible for a client to offer multiple application protocols if these constraints conflict.

There are two sections on 0-RTT. These contain contradictory information.

There are two sections on flow control. These seem consistent but redundant.

There are sections on padding and traffic analysis. These could be unified.

None of these sections cross reference each other.

There is value in providing a privacy considerations section (the source of some of these duplications), but the duplication problem can be managed with the use of cross references.

On 3/6/2020 6:12 AM, Tony Finch wrote:

Section 5.7.1 (connection reuse): possibly also worth stating that servers
should not send responses in order. Maybe refer to RFC7766 which has
similar requirements for TCP.

ASCII art tables:

The "doq" string identifies DoQ:

    Protocol:                 DoQ
    Identification Sequence:  0x64 0x6F 0x71 ("doq")
    Specification:            This document

Are not accessible. Please use definition lists.

In kramdown this would be:

The "doq" string identifies DoQ:

Protocol:
: DoQ

Identification Sequence:
: 0x64 0x6F 0x71 ("doq")

Specification:
: This document

On 3/6/2020 6:12 AM, Tony Finch wrote:Section 5.4 (response size): there was a HUGE discussion about this in the
context of DoH and the consensus was to retain the 65535 byte message
size limit. DoQ should do the same.

see: https://mailarchive.ietf.org/arch/msg/doh/fpJSGWI1YtHeTFvmrS7pvB7ZnDA/

The EDNS payload size limit only applies to Do53 UDP and should be ignored
in other transports.

Servers can get lots of efficiency gains if they can assume that a query always fit in a single packet. DNS Queries are normally short. Even if we assume a few EDNS options, they should rarely be more than a few hundred bytes. Normally a query can fit in a single STREAM frame that both creates and closes the stream.

I would like to somehow mandate that, but it is a bit of a layer violation. What do you think?

How about enabling a stateless server implementation? Let's suppose that clients would send both a resume request and a 0-RTT query in a single UDP message. The server could send the response as 1-RTT data and just close the connection, without keeping any state.

Your error codes are an extension point that isn't being exercised. In HTTP/3 we GREASE all extension points like error codes to avoid ossification. Something to consider here too.

The "one query per stream" architecture allows clients to open as many streams as they want, and thus submit as many outstanding requests as they want. Clients could in theory open a large number of streams and flood the server.

The transport level flow control in QUIC provides some defense, but it only limits the number of outstanding packets. A single QUIC packet could carry many stream openings, so this is a blunt instrument. A server under stress could use RST-STREAM to perform the equivalent of dropping a packet in UDP over DNS. But then, this creates another issue: a good client may just be sending many requests for good reasons, and may start experiencing bad service due to streams being reset.

The client could pace itself by limiting the number of outstanding queries. But how does it know how much is enough and how much is too much?

This affects stream actions more than connection actions. But you should probably state what happens if an unknown code is received. I suggest it is treated as if DOQ_NO_ERROR was received.

The properties of padding using QUIC PADDING frames and padding of DNS messages are greatly different. If the choice to recommend use of QUIC padding is deliberate, the draft should talk about why that is the right choice, because it is not obviously so. It should also then talk about the shortcomings of that sort of approach, particularly as it relates to how packet loss can affect the efficacy of padding.

The Notify transaction is defined in RFC 1996, which is an old-style RFC describing how a "master" can notify "slaves" when the master zone has been updated, so the replicas can quickly fetch the updates.

RFC 1996 has text describing how to send the NOTIFY transaction over UDP or TCP. UDP is easy: the origin just sends UDP packets to the replica servers. I think that assume that these replica servers are listening on UDP port 53. After all, they full fledged DNS servers. The text on TCP says:

• The transport protocol used for a NOTIFY transaction will be UDP unless the master has reason to believe that TCP is necessary; for example, if a firewall has been installed between master and slave, and only TCP has been allowed; or, if the changed RR is too large to fit in a UDP/DNS datagram.

I looked in RFC 1996 for a definition of who would initiate the TCP connection. That is not clear at all. The plausible interpretation is that the origin just sets up a TCP connection to the replica server, and then sends the Notify request and awaits the Notify response. In DoQ, the equivalent of that would be having the origin act as a DoQ client, and the replica server acts as a DoQ server. Once the DoQ server has been notified of an SOA update, it can turn back, open a DoQ connection to the origin server, and request an XFR over that. I think the spec, as is, supports that behavior. We may want to add an annex explaining that.

Of course, there is another interpretation, that the replica server will set a long duration connection to the origin server, and that the origin server will occasionally "push" a NOTIFY transaction over that connection. Of course, having the server sends requests over an established connection is not hard: just let the server open streams from the server-reserved range, and push transactions on these streams. This could render DoQ completely symmetric. But if we do that, we have to worry about what happens if there is no connection available between origin and replica, and that bring back things like long duration connection, keep alive, and the like. That's a lot of overhead, with keep alive messages every 30 sec or so, and it still does not guarantee that the connection will not break...

On 3/6/2020 6:12 AM, Tony Finch wrote:

Christian Huitema [email protected] wrote:

We just resubmitted the DNS over QUIC draft to DPRIVE. Thanks in advance
for the feedback!
Looks promising! I have a few comments:

Is the ALPN "dq" or "doq"? 4.1 and 4.1.1 appear to disagree. 8.1 seems to
disagree with itself.

Blame my poor editing skills, and use "doq". Sorry.

I am reading the discussion of 0-RTT issues on the TLS list. The general feeling is that 0-RTT is like candy, and we are not going to stop developers from using it, even if there is a serious risk of replay attacks. Which means that even if we write that "deployments MUST NOT use 0-RTT", we are really using the RFC 6919 "MUST (BUT WE KNOW YOU WON'T)", or rather "MUST NOT (BUT WE KNOW YOU WILL)".

So, instead of saying "don't do it", we would be better off explaining the risk (replay attack) and describing a possible mitigation. One class of mitigations is to detect replays. In QUIC, we could for example detect replay of the same resume token.

On the other hand, this seems to be really a QUIC-level problem, rather than DNS-level. What do others think?

The client MUST send the DNS query over the selected stream, and MUST indicate through the STREAM FIN mechanism that no further data will be sent on that stream.

The length prefix tells the server how much request to expect, so it can produce a response. But if FIN doesn't follow, what is a server to do? The client isn't obligated to send FIN together with the query. Maybe the FIN was in a different frame and that frame got lost (a bad idea, but possible). That means that the server can't police this without resorting to use of timers and the like.

Some text would be appreciated.

In his review of PR #59, @martinthomson suggests to replace references of style as defined in section 4.1.2 of {{!RFC9001}} by more precise referencing as defined in {{section 4.1.2 of RFC9001}}. New versions of Kramdown can process these more specific references, and provide better indexing.

There seems to be no mention of unidirectional streams. Since you don't define any use of them, you might want to add recommendations to STOP_SENDING them all.

I think that not supporting DSO was entirely a choice on the part of the authors. An extension could be defined that would make DSO possible. There are some interesting questions to answer there (particularly around the use of authentication and how reference identities are used), which is why I support keeping it out of scope. However, this is NOT the same as HTTP in that this entirely new protocol is not prevent by existing constraints from adding this communication mode; it is merely a choice.

On that basis, I would suggest that the following be amended:

[...] DSO is not applicable to DNS over HTTP since HTTP has its own mechanism for managing sessions, and this is incompatible with the DSO; the same is true for DoQ.

(That sentence is already a run-on, by the way.)

I would suggest something like:

This definition of DoQ does not include support for DSO.

And maybe also:

A revision or extension to this specification might define the use of DSO with DoQ.

The most obvious issue I assume was a simple mistake:

Support for advanced error recovery procedures as specified in "QUIC Loss Detection and Congestion Control"

Surely "error recovery" should be "loss recovery" since losses aren't really "errors" in the common sense of the word. I also don't really see how this part of QUIC is relevant to a DNS over QUIC mapping.

I also don't see why this section mentions HTTP and "latency" at all. QUIC was indeed designed in lockstep and by those with a particular interest in HTTP, but the section seems to imply it was designed for HTTP in particular, which isn't true and doesn't seem very relevant to a DNS mapping.

To me it seems like there are two relevant things for a DNS over QUIC mapping worth calling out here: 0RTT and multiple independent streams. The former is relevant because it's very useful to minimize latency for DNS queries. The latter is relevant because QUIC provides an application semantic for multiplexing queries over a single connection.

DNS over QUIC assumes that clients will pick a stream, say #3 for the first query with query ID = 1 and #5 for the second one with query ID = 2. It also assumes that the server response is sent back on the same stream over which the query was received. But what if the server is confused, and sends the response to query ID = 2 on stream #3, and the response to query ID = 1 on stream #5? What is the client supposed to do?

In an email to the draft authors, Paul Hoffman wrote: I see that you want a system port for DoQ. That makes sense for looking "official", but it greatly delays the ability to reference the port before IETF Last Call on draft-ietf-dprive-dnsoquic. Could I propose instead that you take one from the user port space, and apply for it now? You have a WG-adopted draft, and one of you is even part of the expert review team for ports. You could even ask for a cute one that ends in "53".

The thread went on, pointing out that 8853 would be a good choice.

DoQ can be used in three main roles: stub to recursive, recursive to authoritative, and XFR, plus maybe the use of NOTIFY from primary to secondary. These have different requirements. The current privacy requirements apply mostly in the stub to recursive category; the cache attack, for example, may not really apply to authoritative servers. We need to specify these differences.

On 3/6/2020 6:12 AM, Tony Finch wrote:

Sections 5.7 (Connection Handling) and 4.3 (Connection Management) seem to be restating the same things in different ways. They should probably be merged into one.

Just got this from [email protected], on 4/11/2017:

Hi Christian,

I've read draft-huitema-quic-dnsoquic-00 and noticed section 9.2 is requesting a reservation for port 953. To my knowledge, that one is already in use by DNS Bind tool 'rndc' and could be a possible conflict.

As that is a default (changeable) Bind config and not official registered port, I guess a notice would suffice.

Best regards,
Michiel Klaver

I think that this is incorrect:

For the zone transfer scenario, it would be possible to replay an XFR QUERY that had been sent in 0-RTT data. However the authentication mechanisms described in RFC9103 ("Zone transfer over TLS") will ensure that the response is not sent by the primary until the identity of the secondary has been verified i.e. the first behavior listed above.

If mutual authentication is used on an original connection, a subsequent connection can use 0-RTT and retain all authentication information. This means that XFR could be initiated in 0-RTT.

Furthermore, replay protections depend on the server not doing anything with what was in the 0-RTT request. I don't know whether XFR might result in actions that are non-idempotent or unsafe (using HTTP terms here for lack of better - maybe "without side effects" is better). If something does happen, then the condition you rely on does not hold.

It might be better to remove this text and rely on the generic advice.

"Explore the characteristics of using QUIC as a DNS transport" is set out as a goal.

I would recommend that this be removed as a goal. We're past that point.

The use of session resume is flagged as a privacy risk in the privacy considerations. The text in section 5.4 points to the privacy analysis in section 8.2 and says:

... Stub resolvers SHOULD consider
potential privacy issues associated with session resume before
deciding to use this mechanism.

And the text in section 8.2 says:

Enabling the server to link client sessions through session resume is
probably not a large additional risk if the client's connectivity did
not change between the sessions, since the two sessions can probably
be correlated by comparing the IP addresses. On the other hand, if
the addresses did change, the client SHOULD consider whether the
linkability risk exceeds the privacy benefits. This evaluation will
obviously depend on the level of trust between stub and recursive.

This text is of course a bit whishy washy. There is another facet to this mechanism. Session resume consumes fewer resource on the server than establishing a new session. That means stubs should be encouraged to resume sessions, unless this will break privacy.

Allison suggests that "we might want to mark the MAY use resume despite privacy problems as an open question, because the tradeoff of not having fast open is a problem. But we'll know more once the implementations look at this."

QUIC splits the error code space between "connection errors" that use error codes defined in the QUIC transport spec, and "application errors" that use error codes defined per application. Application level error codes are used in Reset Stream, Stop Sending, and Application triggered Connection Close. We probably need to add a section to the spec formally defining these error codes.

The text on use of 0-RTT is extremely thin. Some people have noted that 0-RTT for queries is not always as simple as this draft implies. For instance, if a server produces different responses for load balancing in a round-robin fashion, using 0-RTT can leak information about the contents of queries if an attacker is able to execute a retry. At a caching resolver, a query can also have a side effect in that it can result in the creation of a cache entry, which can be observed by an attacker (this is generally managed by having a replay window smaller than the minimum cache validity period).

RFC 8470 talks about different strategies for managing 0-RTT that might also apply here, such as holding responses until the handshake completes. These should also apply to DNS.

You probably also want to talk about why you believe queries are safe to send: that is, you expect them to be side-effect free (though see above) and not state modifying.

The text should cite TLS-level requirements as well.

There is probably more than I can think of at 5am in the morning, while trying to listen to an active session. Take some time to think about this carefully.

In the IETF 111 meeting a request was made to clarify that 'the lack the support of server initiated transactions' did not mean that NOTIFY could not be done over DoQ

In section 5.4, there is a hyperlink to Sec 10.1 of RFC 9000, that instead leads to Sec 10.1 of dnsoquic.

It might be that 3 is all you ever need, but this is good practice. I recommend borrowing QUIC policies.

There are a few places in which QUIC concepts are explained in quite some detail. Section 5.6 explains specific transport parameters. You don't need to do that. It uses a lot of words. DoT doesn't go into the details of how TCP provides flow control, so this doesn't need to either.

I like that the document recommends use of the idle timeout, but you don't need to explain all the ways in which QUIC connections might terminate along with that.

Section 6.3 repeats requirements of QUIC regarding address validation.

Mostly this is just editorial work that should reduce the size of the document.

On 3/6/2020 7:30 AM, Paul Hoffman wrote:

Thank you for continuing this interesting work. However, a reader might not realize that many other folks would prefer DNS/HTTPS/QUIC until the get all the way to Section 3.4. Also, the title of that section seems a bit unbalanced, given that the text says that people might prefer DNS/HTTPS/QUIC for reasons other than hiding from firewalls.

For a future version of this draft, please consider moving the comparison to DNS/HTTPS/QUIC, and the discussion of not knowing which one folks will prefer, up to the Introduction. That would leave Section 3.4 just about the stated design goal.

Yes. I would like to end up with just a spec, and leave the discussion
about DoT vs DoQ vs DoH vs DoH3 to some other document...