I share Sara's position. On Thu, Jan 27, 2022 at 08:18 Sara Dickinson <[email protected]> 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 <[email protected]> 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 > >> [email protected] 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/dns-privacy > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
