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

From: Martin Duke <[email-masked]>
Date: Mon, 6 Dec 2021 11:55:40 -0800

Thank you for the changes in draft-07.

from Christian's response:

>> 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.

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?

As the current text says, Sec 3.5 of RFC 9000 is the correct reference. I
would recommend

s/if the server has already sent the response/if the server response has
already been acknowledged

<snip>

>> 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.

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.

RFC8999 does not guarantee that future versions of QUIC will preserve the
QUIC bit, which allows demultiplex of DTLS with QUIC. DTLS has no
invariants at all. I share your skepticism that this will end up mattering;
however, there ought to be a little text, that says, e.g.,

Deployments that serve DNS over DTLS [RFC8904] and DNS over QUIC version 1
on the same port will be able to demultiplex the two due to the second most
significant bit in each UDP payload. Such deployments ought to check the
signatures of future versions or extensions (e.g.
[?I-D.ietf-quic-bit-grease]) of QUIC and DTLS before deploying them to
serve DNS on the same port.

On Mon, Oct 18, 2021 at 7:48 AM Sara Dickinson <[email-masked]> wrote:

>
>
> > On 15 Oct 2021, at 01:47, Christian Huitema <[email-masked]> wrote:
> >
> >
> > On 10/14/2021 12:06 PM, Martin Duke wrote:
> >> 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:
> >>
> >>> Note: I review this as a QUIC enthusiast, but at best a novice with
> DNS.
> >>>
> <snip>
> >
> > Do you want to suggest a better text?
> >
> >>> 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?
> > 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.
>
>
>
>
>

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 6 Dec 2021 17:30:16 -0500

On Mon, Dec 6, 2021 at 2:56 PM Martin Duke <[email-masked]> wrote:

> DTLS has no invariants at all.
>

Is this true?  It seems to me that DTLS inherits TLS's implicit
compatibility guarantee: all DTLS 1.x ClientHellos must also be valid DTLS
1.0 ClientHellos.  That is a very tight invariant.

I'm not sure if this is written down anywhere, but then this whole
"invariant" notion is very new and essentially specific to QUIC.

---

From: Martin Duke <[email-masked]>
Date: Mon, 6 Dec 2021 14:34:02 -0800

Thanks Ben, that's a more accurate statement than mine.