I share Sara's position.
On Thu, Jan 27, 2022 at 08:18 Sara Dickinson <sara@xxxxxxxxxxx> wrote:
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 <huitema@xxxxxxxxxxx> 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
>> 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
