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
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?
_______________________________________________
dns-privacy mailing list
dns-privacy@xxxxxxxx
https://www.ietf.org/mailman/listinfo/dns-privacy
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
