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

I share Sara's position.

On Thu, Jan 27, 2022 at 08:18 Sara Dickinson <sara@sinodun.com> 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@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
>
>