Hi Brian, Thanks for the review, and as Christian said the padding question has been a point of discussion.
I’m personally comfortable with a downref to RFC 8467 with text to support why this is done as you suggest. Multiple studies have shown just how easy traffic analysis is without any padding - we could actually cite one of the more recent ones. RFC 8467 is implemented for stub-recursive DoT in most open source software and is in use by major recursive operators. For me this approach mitigates the immediate risk of exposing DNS names - preventing traffic analysis from identifying DoQ is a much longer term goal (and requires ECH). I’ve had a first pass at a PR making RFC8467 normative here: https://github.com/huitema/dnsoquic/pull/143 Regards Sara > On 26 Jan 2022, at 20:32, Christian Huitema <[email protected]> wrote: > > Thanks for the review, Brian. > > We have been going back and forth on the padding requirements, and the > current text is specifically written to avoid a downward reference to RFC > 8467. You are making a good arguments that it is hard for implementers to > comply with a requirement that they MUST pad if there is no specific guidance > about how to pad. On the other hand, I think that we should not delay > publication until getting definitive agreement on the appropriate padding > policy. For example, we would have to resolve the tension between application > specific padding, with a goal to hide which DNS names are being queried, and > generic transport level padding, with a goal to prevent traffic analysis from > distinguishing between DoQ and other applications. So, I am inclined to just > replace MUST by SHOULD, and leave it at that. That's one of your proposed > remedies, but I wonder whether others might object. > > -- Christian Huitema > > > On 1/24/2022 5:05 AM, Brian Trammell via Datatracker wrote: >> 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 >> [email protected] 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? >> >> >> _______________________________________________ >> dns-privacy mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
