[dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-dnsoquic-10: (with COMMENT)
Martin Duke via Datatracker <noreply@ietf.org> Wed, 09 March 2022 17:41 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: dns-privacy@ietf.org
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB463A0EF2; Wed, 9 Mar 2022 09:41:04 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Duke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dprive-dnsoquic@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org, brian@innovationslab.net, dns-privacy@ietf.org, brian@innovationslab.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke <martin.h.duke@gmail.com>
Message-ID: <164684766454.27683.16970508061933986550@ietfa.amsl.com>
Date: Wed, 09 Mar 2022 09:41:04 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/eQt8xOUoiPZOOQZWDQporGmrzDA>
Subject: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-dnsoquic-10: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Mar 2022 17:41:13 -0000
Martin Duke has entered the following ballot position for draft-ietf-dprive-dnsoquic-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this draft! It was very easy to read. (4.3) says: "Using QUIC might allow a protocol to disguise its purpose from devices on the network path using encryption and traffic analysis resistance techniques like padding. This specification does not include any measures that are designed to avoid such classification." but then Sec 6.4 has a detailed, normative discussion of how to use padding to avoid classification. I suggest you delete or edit the bit in 4.3. (5.3.1) Clients are allowed to send STOP_SENDING and servers are allowed to send RESET_STREAM. Servers sending STOP_SENDING break the connection. Given the prescriptiveness of these rules, it's odd that you don't address clients sending RESET_STREAM. IMO this should be allowed, but either way it should be specified. (6.5.4) and (9.4) I hesitate to write this, as Christian is as well aware as anyone, but IMO QUIC address migration is not quite as privacy-destroying as this draft suggests. RFC9000 has a number of normative requirements to reduce linkability, and work is ongoing to reduce it further. Granted, no anti-linkability mitigation is perfect, and if this is a primary goal of DoQ it's OK to discourage migration as you've done here.
- [dns-privacy] Martin Duke's No Objection on draft… Martin Duke via Datatracker
- Re: [dns-privacy] Martin Duke's No Objection on d… Sara Dickinson
- Re: [dns-privacy] Martin Duke's No Objection on d… Martin Duke