Re: [dns-privacy] Murray Kucherawy's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

Sara Dickinson <sara@sinodun.com> Thu, 06 May 2021 11:53 UTC

Return-Path: <sara@sinodun.com>
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 F023D3A1EF7; Thu, 6 May 2021 04:53:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.com
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 4GKhPRQfAbzq; Thu, 6 May 2021 04:53:32 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 846ED3A1F15; Thu, 6 May 2021 04:53:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=Kcov0dlJIFZ3uTtjDfwVqNJC2XfxTgD1FvF1olRbBo8=; b=Q3XHzgxYCq9vLW7tukiqmmuDAa U4PqCLNEy2AKfpTu+C4khzIbZhh7Rw+Uvm3XhD1ltIljzBdCRxbU0HV8UobTPxaL/ETfhGkollY3q dx7gG7zyp0LtuXX1is0ufJvTCWKyLp0c638/4t+GnEnSB3fxpKgzhyxYXZAfQmDeJM4l66VtVpQ1l YbWTavKNvNSZmsy4dq662A2c5AKivSilTt3OzF1xNAzBBQZacArsBf6hfeqBtOii96yVqg7IFFY4O 8kB/uom0dcFMQ6cIwNBBSJsdpxW0reutEJxRB/Ur1xCZT0XuPkvAQV1Izj3sSzRwwWeIafk3BHOFu Y1XG3ERQ==;
Received: from [62.232.251.194] (port=9906 helo=[172.27.240.5]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <sara@sinodun.com>) id 1lecZM-0000pk-PG; Thu, 06 May 2021 12:53:29 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <162028190664.14000.16746761589914077982@ietfa.amsl.com>
Date: Thu, 6 May 2021 12:53:21 +0100
Cc: The IESG <iesg@ietf.org>, draft-ietf-dprive-xfr-over-tls@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org, tjw.ietf@gmail.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <23EF5929-AC98-44FE-B306-FE16B3852F2A@sinodun.com>
References: <162028190664.14000.16746761589914077982@ietfa.amsl.com>
To: Murray Kucherawy <superuser@gmail.com>
X-Mailer: Apple Mail (2.3445.104.20)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/YWmeSG0tuBUm1TycKDbAv8I2m0E>
Subject: Re: [dns-privacy] Murray Kucherawy's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)
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: Thu, 06 May 2021 11:53:37 -0000


> On 6 May 2021, at 07:18, Murray Kucherawy via Datatracker <noreply@ietf.org> wrote:
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-dprive-xfr-over-tls-11: 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/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> With my BCP 14 language complainer hat on:
> 
> Section 7:
> 
> * "Implementations SHOULD use [RFC7828] [...] to manage persistent
> connections." -- since this is a SHOULD, can you suggest why an implementer
> might opt not to do this?  Section 7.3.1 does a great job of handling the
> SHOULD it presents, for example.

Implementations typically include an option to use fixed timeouts on either side of a connection for simplicity which can work just fine for e.g., low transfer rates - I could add text to that effect?

> 
> Sections 7.3.2 and 7.3.3:
> 
> * Same issue as above with the SHOULDs here.

Short answer, backwards compatibility.

For 7.3.2 there was a discussion in the working group about the significant code complexity involved for several implementations to meet all 3 requirements (particularly the second two points).  Since the performance improvements gained from these features is desirable, but not a critical for XFR, the discussion resulted in the SHOULD. Again, could add text on that if needed?

For 7.3.3, there is no previous specification for this behaviour and nameservers may behave differently today, hence the SHOULD here. 


> 
> Section 7.4:
> 
> * "Therefore, it is RECOMMENDED that [...] there SHOULD be no more than [...]."
> -- I don't know how to reconcile this RECOMMENDED-SHOULD combination in the
> same sentence.  I suggest that the first clause can be dropped with no loss of
> meaning.

Double checking this I remembered that for consistency the text is actually lifted and tweaked from RFC7766 which it is updating which said:
“It is RECOMMENDED that for any given
   client/server interaction there SHOULD be no more than one connection
   for regular queries, one for zone transfers, and one for each
   protocol that is being used on top of TCP (for example, if the
   resolver was using TLS). "

So we could update it if you feel very strongly?

> 
> Everything else is nits, some of which were probably also mentioned by others:
> 
> Section 1:
> 
> * "authoritatives" should probably be "authoritative nameservers"
> 
> * "authenticated denial of existences records" -- s/existences/existence/
> 
> Section 4:
> 
> * "The proposed mechanisms does not attempt" -- s/does/do/, or
> s/mechanisms/mechanism/
> 
> Section 6:
> 
> * "term is used to encompasses" -- s/encompasses/encompass/, or remove "is used
> to"
> 
> Sections 6.1 and 6.2
> 
> * "higher than the secondaries serial" -- s/secondaries/secondary's/
> 
> Section 6.2:
> 
> * "So there may be a fourth step above where [...].  There may also be a fourth
> step where [...]." -- so there can be two "fourth" steps?
> 
> Section 6.3:
> 
> * "This section attempts to presents" -- remove "attempts to", or
> s/presents/present/
> 
> * In the second paragraph, I think you need a comma after "servers”.

Thanks for these - some but not all were caught by others!

Regards

Sara.