Subject: [dns-privacy] WGLC review for draft-ietf-dprive-dnsoquic-05

From: Martin Duke <[email-masked]>
Date: Thu, 14 Oct 2021 11:59:47 -0700

Note: I review this as a QUIC enthusiast, but at best a novice with DNS.

I support this work and would like it to move forward. However, I have a
few minor concerns.

1. In the introduction, it would be helpful to describe the benefits of DoQ
with respect to DoHTTP/3. The latter obviously is also over QUIC, gets many
of its protocol benefits, and can also leverage the existing DoH design. So
why DoQ?

2. (Sec 5.3.1) It doesn't quite sit right that STOP_SENDING can be ignored
if all data has been "sent". If some all has been sent but only some
acknowledged, the receiver of STOP_SENDING should stop trying to retransmit
any unacknowledged data.

3. (Sec 5.5) I don't understand the status of this NOTIFY analysis. Will
the document hold until the analysis is complete, or is this an independent
process and you are planning to publish with the statement as-is?

4. (Sec 5.5) Is there not a role for intermediaries in this architecture?
I'm thinking of the HTTP header field that notifies the server that the
request arrived in early data, even though on the last downstream
connection was 0RTT. Is the intent that all the termini in the chain will
reject QUERY if early data, as described here?

5. (Sec 9.1) It might be worthwhile to point out that 0RTT requests are not
forward secure.

6. (Sec 10.2) Section 17.2 in [RFC9000] doesn't say anything explicit about
demultiplexing with DTLS or any other protocol. A danger in reusing Port
853 is that it implicitly limits use of DoQ with future versions of QUIC.
At the very least, it would be useful to explicity write down the
requirements for DoQ over future versions of QUIC.

Thanks,
Martin

---

From: Martin Duke <[email-masked]>
Date: Thu, 14 Oct 2021 12:06:40 -0700

Update: Rui Paulo points out that
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc7983bis-01 is
the best reference for QUIC demultiplexing.

On Thu, Oct 14, 2021 at 11:59 AM Martin Duke <[email-masked]>
wrote:

> 1. In the introduction, it would be helpful to describe the benefits of
> DoQ with respect to DoHTTP/3. The latter obviously is also over QUIC, gets
> many of its protocol benefits, and can also leverage the existing DoH
> design. So why DoQ?
>
> 5. (Sec 9.1) It might be worthwhile to point out that 0RTT requests are
> not forward secure.
>
> 6. (Sec 10.2) Section 17.2 in [RFC9000] doesn't say anything explicit
> about demultiplexing with DTLS or any other protocol. A danger in reusing
> Port 853 is that it implicitly limits use of DoQ with future versions of
> QUIC. At the very least, it would be useful to explicity write down the

---

From: Christian Huitema <[email-masked]>
Date: Thu, 14 Oct 2021 17:47:25 -0700

>> many of its protocol benefits, and can also leverage the existing DoH
There were actually quite a few discussions of that in the working group 
when we first created this draft. That's why the title of the draft 
mentions "dedicated QUIC connections". We agreed at the time to just 
work on the direct mapping of DNS over QUIC, in parallel to the obvious 
mapping of DNS over H3. I would rather not start adding a discussion of 
why one is better than the other. We could add a statement of 
differences: direct mapping does not include any HTTP code, which 
reduces overhead and attack surface; but, direct mapping does not reuse 
the HTTP infrastructure in the way DoH would. Note that the exact same 
difference apply to DoH versus DoT.
>> acknowledged, the receiver of STOP_SENDING should stop trying to retransmit

RFC 9000 is pretty much silent on that point. There is no mention of 
STOP_SENDING in section 3.1 of RFC 9000. Everything in RFC 9000 looks 
like "it would be nice if you stop sending asap", without making that a 
hard decision. Yes, we might mention acknowledgements, but this is a 
QUIC level issue. QUIC stack APIs may or may not inform the application 
about how much data on a stream has been acknowledged, and in this 
particular case data might well be acknowledged at the QUIC layer and 
discarded at the application layer.

Do you want to suggest a better text?

>> process and you are planning to publish with the statement as-is?
I will let Sara answer this specific question.
>> reject QUERY if early data, as described here?
No, there are no intermediaries in this architecture. This is basically 
the same design as DoT.
>> 5. (Sec 9.1) It might be worthwhile to point out that 0RTT requests are
OK.
>> requirements for DoQ over future versions of QUIC.

As the text says, no deployment of RFC8904 currently exists to our 
knowledge. The reliance on section 17.2 of RFC 9000 is really an 
assurance against a very unlikely eventuality, and I cannot see how it 
would impact future versions of QUIC.

-- Christian Huitema

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 18 Oct 2021 15:48:53 +0100

> On 15 Oct 2021, at 01:47, Christian Huitema <[email-masked]> wrote:
> 
> 
<snip>
> I will let Sara answer this specific question.

Thanks for pointing this out - the text does need updating one way or there other.

We’ve had no feedback to date on this question, so on the basis that no-one has objected to sending a NOTIFY in 0-RTT data, I’ve opened a PR to update the text to allow this: https://github.com/huitema/dnsoquic/pull/114

Regards

Sara.