Re: [Tsv-art] [dns-privacy] Tsvart last call review of draft-ietf-dprive-dnsoquic-08
Christian Huitema <huitema@huitema.net> Wed, 26 January 2022 20:33 UTC
Return-Path: <huitema@huitema.net>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC73B3A1F6C for <tsv-art@ietfa.amsl.com>; Wed, 26 Jan 2022 12:33:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 744uNKAdPlhv for <tsv-art@ietfa.amsl.com>; Wed, 26 Jan 2022 12:33:10 -0800 (PST)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A36E3A1F6D for <tsv-art@ietf.org>; Wed, 26 Jan 2022 12:33:10 -0800 (PST)
Received: from xse.mail2web.com ([66.113.192.6]) by mx135.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1nCoyX-000BZm-R3 for tsv-art@ietf.org; Wed, 26 Jan 2022 21:33:08 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4Jkb5D5zVRzDFT for <tsv-art@ietf.org>; Wed, 26 Jan 2022 12:33:04 -0800 (PST)
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1nCoyW-0002Ub-MZ for tsv-art@ietf.org; Wed, 26 Jan 2022 12:33:04 -0800
Received: (qmail 28164 invoked from network); 26 Jan 2022 20:33:00 -0000
Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.84]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ietf@trammell.ch>; 26 Jan 2022 20:32:59 -0000
Message-ID: <e81b7117-126a-4557-b020-eb5dbffa775b@huitema.net>
Date: Wed, 26 Jan 2022 10:32:55 -1000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
To: Brian Trammell <ietf@trammell.ch>, tsv-art@ietf.org
Cc: draft-ietf-dprive-dnsoquic.all@ietf.org, last-call@ietf.org, dns-privacy@ietf.org
References: <164303671825.29006.13435316265266313857@ietfa.amsl.com>
From: Christian Huitema <huitema@huitema.net>
In-Reply-To: <164303671825.29006.13435316265266313857@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: 66.113.192.6
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.192.0/27
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.0/27@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5zePHE09KK/spagAHQf6B6A8wOq2zirMPonLyKNm5/pImaT Q1xXWexHxw79xhFM5gQk4Ndu06h2Q8QP5GQeNUYfy7FVClXO3qMFrsEn1zvL4G/bWfgucjnNmABp GhD9TTvAFcsS88n3hwHBjNBhToY4kFiTWd5VkIvATzhk5mxheohSnw9YyoGHx/ukuag1WKBI/pQA McbcRFWBlvgrwEv2lcwC8edOyTFsJvTBZdmGd2GfqymzSheinRamXab6WeU3IICByTDlBVbfm35D zkfatWYAD+wEZQw6xBZnPra86y0KEAnwyE9dte+FkDKSV99EDBffVZVjmVaNbG4ZJG7FlTxBorin YuGwbPAkkzSJcowdnlomQCrO3j+vL2SMJPspcvZoI7P90p8oLprk3TF7EVBannnL7tRRK/uB8nvA 5fMcRdQ8d/qPm/Bxf+EhGJQ/D6zTl4mA8RSJ/S9uDS1kaz28F/27QkRL/GPw/1iWGtfNeYdo3zQk L6d8fnrVN7/oG2luZ2kwu8znxkHgZW9l++DuIQUs/5JJj4C/n4CILoSsHDfCj8mORrpsmK4H3U2o F64NkCu6YlwNcLgEJ289KrwFKe+X5/UuhfHXv7PiZ0Vd1w5debfz/740qdCtT+3r1eXTpx/atMNj hVwNBNqNwxHemKZb4fqGsuztuKEz56ntKr6+crm+rffkaQ6ZgOgwg8gZ3WJY10Ou68XRBzIVfz8h 2tj4aloLqSd3UIr8MZx6JD3sqzv6t7SDNnrCXHOxhfadNbS0Jrm63hSE5XeywD/3EaCPu1onFa0d n3u5ijf5aNqi6hngy6x7q/OcGwvrjuU3A3io6xJmD59iFVkbnwDeFIKLbigMxsr64XiGf7nEuBIf 2/mJcK3z1PGTE5EWpi665IAVZCxuthgQGWxOmdySlZou9qHIGOZDEEo7O57ndBJXbfc50e+liu8J BA7sp0dpQMu8VlyuxYry6DXIAezEFeM7/Pa26Cv3VwRoQA==
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/fASkt9PQCpVJb9CO_VhO59Fuz-k>
Subject: Re: [Tsv-art] [dns-privacy] Tsvart last call review of draft-ietf-dprive-dnsoquic-08
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2022 20:33:13 -0000
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
- [Tsv-art] Tsvart last call review of draft-ietf-d… Brian Trammell via Datatracker
- Re: [Tsv-art] [dns-privacy] Tsvart last call revi… Christian Huitema
- Re: [Tsv-art] [dns-privacy] Tsvart last call revi… Sara Dickinson
- Re: [Tsv-art] [dns-privacy] Tsvart last call revi… Allison Mankin
- Re: [Tsv-art] [dns-privacy] Tsvart last call revi… Brian Haberman
- Re: [Tsv-art] [dns-privacy] Tsvart last call revi… Daniel Kahn Gillmor
- Re: [Tsv-art] [dns-privacy] Tsvart last call revi… Brian Trammell (IETF)
- Re: [Tsv-art] [dns-privacy] Tsvart last call revi… Allison Mankin
- Re: [Tsv-art] [dns-privacy] Tsvart last call revi… Sara Dickinson