Reviewer: Brian Trammell Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. This document is a mature and straightforward mapping of DNS over QUIC, modeling a QUIC connection as equivalent to DNS over TCP with one query per stream. 0-RTT and fallback design choices are reasonable and well-explained. Security and privacy considerations are well-presented. All in all, a very good example of an application mapping over QUIC. I have only a few nits here: Editorial nits: - in section 5.3.1, is STOP_SENDING spelled "STOP_SENDING" or "Stop Sending"? Please choose one. - "These privacy issues are detailed in Section 9.2 and Section 9.1" is a weird order; please swap. Content nit: I understand the intent behind "Implementations MUST protect against the traffic analysis attacks described in Section 9.5 by the judicious injection of padding"; however (1) there is no interoperability risk from failing to comply with this restriction, and (2) as an implementor, it would not be clear to me how to prove my padding injection was "judicious". There is a reference to an experimental RFC 8467 that presumably defines acceptable padding policies, but it is referenced as "should consider". I would recommend one of the three following remedies: - change this to a SHOULD (since verifying compliance is impossible as phrased), - add a normative downref to 8467 and make it clear that that reference defines padding policies considered compliant, or - provide some other guidance implementors can use do determine whether they are padding enough to be considered compliant. Further, traffic analysis threats are not limited to packet lengths, as section 9.5 acknowledges. Is there any equivalent MUST guidance regarding stream frame timing for traffic analysis resistance that could be given here? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
