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 protected]>
wrote:
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?
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.
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?
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.
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?
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
not forward secure.
OK.
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.
-- Christian Huitema
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
