Re: [dns-privacy] Tsvart last call review of draft-ietf-dprive-dnsoquic-08

[Christian Huitema <[e-mail]>]

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
> [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy