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
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
