I support the additional text on padding.As a process note, I believe we will need to re-issue the IETF Last Call to allow for the discussion of the down-ref to 8467.
Regards, Brian On 1/27/22 8:36 AM, Allison Mankin wrote:
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 SaraOn 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 thecurrent 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 reviewteam'songoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to thedocument'sauthors and WG to allow them to address any issues raised and also tothe IETFdiscussion list for information. When done at the time of IETF Last Call, the authors should considerthisreview 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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
