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

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@huitema.net> 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@ietf.org 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy