Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-nsec-ttl

Paul Hoffman <paul.hoffman@icann.org> Wed, 03 February 2021 19:31 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3103A10B0 for <dnsop@ietfa.amsl.com>; Wed, 3 Feb 2021 11:31:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 7jnixSdiHDOa for <dnsop@ietfa.amsl.com>; Wed, 3 Feb 2021 11:31:12 -0800 (PST)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 0CD9C3A10AD for <dnsop@ietf.org>; Wed, 3 Feb 2021 11:31:12 -0800 (PST)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 113JVBCa009452 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Feb 2021 19:31:11 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.721.2; Wed, 3 Feb 2021 11:31:10 -0800
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0721.006; Wed, 3 Feb 2021 11:31:10 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: Michael StJohns <msj@nthpermutation.com>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] Working Group Last Call for draft-ietf-dnsop-nsec-ttl
Thread-Index: AQHW+mMgaMBkvaWdiE69o3JL4SWyjA==
Date: Wed, 03 Feb 2021 19:31:10 +0000
Message-ID: <7A8AD079-63AE-4AEA-830D-5971A7441AA7@icann.org>
References: <CADyWQ+En0_=LzynpgodOyPan0WD5HdtdqVdU6zw39-g_SCNL6A@mail.gmail.com> <edf948c2-f093-9850-805a-5ac05b27a2bd@nthpermutation.com>
In-Reply-To: <edf948c2-f093-9850-805a-5ac05b27a2bd@nthpermutation.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_30B889B0-6C95-48B6-B2C0-2623C053E91C"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-03_07:2021-02-03, 2021-02-03 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Emz_FJhphgdx_cW2rniOpmL631M>
Subject: Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-nsec-ttl
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2021 19:31:13 -0000

On Jan 29, 2021, at 9:31 AM, Michael StJohns <msj@nthpermutation.com> wrote:
> I can't support this as Standards track even though it purports to update standards as it doesn't actually specify an implementable protocol.   Basically, this is dependent upon humans doing the right thing, rather than specifying behavior of the protocol.

I don't understand the context of this. The draft specifies that the protocol is changing, and now authoritative servers change the way they act from $x to $y. Where is the "humans" part?

> For each of these, I'd recommend specifying what a client does in each of the cases, rather than weasel wording the SHOULD with respect to the zone contents to turn this into an implementable protocol.

Here, I agree that the draft is unclear. It should say explicitly "resolvers keep doing $z, there is no change here". Also, for the text about authoritative servers, I agree that changing the SHOULDs from the current standards to MUSTs.

I note that you didn't appear to accuse the authors of 4034, 4035, and 5155 of "weasle wording" when those documents were standardized. Doing so now seems out of line.

> E.g. for each of these clauses add something similar to "The client SHOULD/MUST reduce the effective TTL for the received NSEC RR to the lesser of the TTL of the current SOA record,  the TTL of the SOA, and the TTL of the NSEC RR record and MUST discard the NSEC RR when that effective TTL expires."

Again, this is not about the clients, as the document says (but not clearly enough).

> So - not ready for last call.

Sure it is. These are normal last call comments.

In a similar vein, I think that the section on "No updates to RFC8198" should indeed update RFC 8198. The resolver might have the SOA in its cache, and thus could do the right thing even if the authoritative server has not been updated.

--Paul Hoffman