Re: [dns-privacy] Fwd: New Version Notification for draft-huitema-dprive-dnsoquic-00.txt

Tony Finch <dot@dotat.at> Fri, 06 March 2020 14:12 UTC

Return-Path: <dot@dotat.at>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0A83A077E for <dns-privacy@ietfa.amsl.com>; Fri, 6 Mar 2020 06:12:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 rrCklrFStmK7 for <dns-privacy@ietfa.amsl.com>; Fri, 6 Mar 2020 06:12:13 -0800 (PST)
Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) (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 C48493A077C for <dns-privacy@ietf.org>; Fri, 6 Mar 2020 06:12:13 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:37808) by ppsw-40.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1jADhz-000stV-ki (Exim 4.92.3) (return-path <dot@dotat.at>); Fri, 06 Mar 2020 14:12:11 +0000
Date: Fri, 06 Mar 2020 14:12:11 +0000
From: Tony Finch <dot@dotat.at>
To: Christian Huitema <huitema@huitema.net>
cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
In-Reply-To: <8d4e2a1a-358b-b816-f095-3b4dc52b915f@huitema.net>
Message-ID: <alpine.DEB.2.20.2003061347490.24181@grey.csi.cam.ac.uk>
References: <158346998979.14732.7173381060352492793@ietfa.amsl.com> <8d4e2a1a-358b-b816-f095-3b4dc52b915f@huitema.net>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/RPAdVqehN4I1vLXzgRGGKs6iDac>
Subject: Re: [dns-privacy] Fwd: New Version Notification for draft-huitema-dprive-dnsoquic-00.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Fri, 06 Mar 2020 14:12:19 -0000

Christian Huitema <huitema@huitema.net> wrote:

> We just resubmitted the DNS over QUIC draft to DPRIVE. Thanks in advance
> for the feedback!

Looks promising! I have a few comments:

Is the ALPN "dq" or "doq"? 4.1 and 4.1.1 appear to disagree. 8.1 seems to
disagree with itself.

Section 4.3 (idle timeouts): it's clearly better to use QUIC's facilities
for this, but there could potentially be a conflict with DNS stateful
timeouts (RFC48490) so maybe there needs to be a bit more discussion about
how to resolve disagreements between two protocol layers.

Section 5.4 (response size): there was a HUGE discussion about this in the
context of DoH and the consensus was to retain the 65535 byte message
size limit. DoQ should do the same.

https://mailarchive.ietf.org/arch/msg/doh/fpJSGWI1YtHeTFvmrS7pvB7ZnDA/

The EDNS payload size limit only applies to Do53 UDP and should be ignored
in other transports.

Sections 5.7 and 4.3 seem to be restating the same things in different
ways. They should probably be merged into one.

Section 5.7.1 (connection reuse): possibly also worth stating that servers
should not send responses in order. Maybe refer to RFC7766 which has
similar requirements for TCP.

An editorial suggestion: when referring to RFCs, can you please make it
clear what the reference is about (e.g. the subject of the RFC or name of
protocol) in the paragraph containing the reference, so that readers
can understand the paragraph without having to bounce back and forth to
the references section.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Dover, Wight: Northwest backing west 3 to 5. Slight or moderate. Showers at
first. Good.