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

[Sara Dickinson <[e-mail]>]

> On 6 Dec 2021, at 19:55, Martin Duke <[e-mail]> wrote:
> 
> 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.

Hi Martin, 

Many thanks for this suggested text - I’ve created https://github.com/huitema/dnsoquic/pull/133 to incorporate this which I hope addresses these two comments.

Best regards

Sara.