[DNSOP] Review of draft-ietf-dnsop-rfc5011-security-considerations-13, was Re: [Ext] IETF meeting prep and what

Paul Wouters <paul@nohats.ca> Fri, 18 June 2021 23:11 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 07FDC3A1468 for <dnsop@ietfa.amsl.com>; Fri, 18 Jun 2021 16:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ujkf0IAvPXZP for <dnsop@ietfa.amsl.com>; Fri, 18 Jun 2021 16:11:28 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 E8CB43A1465 for <dnsop@ietf.org>; Fri, 18 Jun 2021 16:11:27 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4G6F6L1fQtzFKJ; Sat, 19 Jun 2021 01:11:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1624057882; bh=+1aYtwSVtHIUdfeD5KHvHC3S93S7u06qsRr4wigDe6o=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XJ9cE2mooALRancIVlE/tMAAy89mvtUacRgjKDSd6jhkYRkTKtltVsAJ3yrPHYOpU IZQlM1WDxBYWR2Xd5hKI57j4JxunHhcYp63rTWApZkAPv1/jYXI4mIt/Hh/u1giaXe DcPFmorFu3tF6VHT3/qqR6pUBJ3kYLadwj95315Q=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id tJApk45_bBfM; Sat, 19 Jun 2021 01:11:20 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 19 Jun 2021 01:11:20 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1DA8585B1E; Fri, 18 Jun 2021 19:11:19 -0400 (EDT)
Received: from localhost (localhost []) by bofh.nohats.ca (Postfix) with ESMTP id 1419885B1D; Fri, 18 Jun 2021 19:11:19 -0400 (EDT)
Date: Fri, 18 Jun 2021 19:11:19 -0400
From: Paul Wouters <paul@nohats.ca>
To: Paul Hoffman <paul.hoffman@icann.org>
cc: Wes Hardaker <wjhns1@hardakers.net>, dnsop <dnsop@ietf.org>
In-Reply-To: <9E1B73F0-D1AA-4510-978E-34A75524CD0C@icann.org>
Message-ID: <341a488c-94f5-a0cb-da99-153cc36086e1@nohats.ca>
References: <CADyWQ+ESB-W9DvdRjCrdXgaZUWzX5b5cUvu-Ue3zjRrVsnCB2w@mail.gmail.com> <5a9b35c5806e36b0802be493d87beb8ef2fef18d.camel@powerdns.com> <ybltulu98e6.fsf@w7.hardakers.net> <9E1B73F0-D1AA-4510-978E-34A75524CD0C@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xddXpmV2qJ_ZmRdD_-zxLvh2EZ8>
Subject: [DNSOP] Review of draft-ietf-dnsop-rfc5011-security-considerations-13, was Re: [Ext] IETF meeting prep and what
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: Fri, 18 Jun 2021 23:11:33 -0000

On Fri, 18 Jun 2021, Paul Hoffman wrote:

>>> I propose replacing rfc5011-security-considerations
>> I keep meaning to republish it with Olafur's suggested reduced title
>> (since it's really describing just one problem).  But it's unlikely to
>> get published as an RFC due to lack of consensus after a long drawn out
>> conversation where most of the WG stopped reading due to the harsh
>> language of some messages.
> For those who don't remember, the lack of consensus was based on too few people speaking to support the document after one WG member kept harshly objecting to some of the wording. This happened well WG Last Call was finished. The chairs decided to kill the document rather than deal decisively with the one obstructionist WG participant.
>> It can probably be dropped from the active
>> list because of this.
> I would like to see the document, which we all already agreed on, moved to IETF Last Call instead.

Background can be read here:


Since then, -13 was published which clarifies the update to RFC 7583 and
made the document Informational:


I used this opportunity to review the document again.

Probably Section 1.2 needs an update because it refers to ICANN plans of 2018. Even if the
plans are unchanged, the date should be bumped to reflect that.

Section 4.2 states:

    2.  Sign the revoked DNSKEY with itself.

This should clarify that we are talking about signing a DNSKEY RRset,
not a single RR.

Similar in 5.1.1:

 	considering the RRSIGs that cover the DNSKEYs in this document.

s/signs the zone's key set with/signs the zone's DNSKEY RRset with/

(more places with "key set" of similar phrasing should be cleared up)

Section 6.1.7 confuses me a bit as it defines a numResolvers variable,
and uses that to calculate an acceptable new timing period. To me it
feels that number of resolvers should not matter, as we should stick
to the formal time where all resolvers are either updated or no longer
updatable. This arguments also bleeds into Section 6.2 where it is used

Appendix A should be updated as well:

 	In 2017 and 2018, ICANN expects to [....]

Assuming Section 6.1.7 is right and just needs a little bit more
explanation, once the above mentioned nits are resolved, I think
this document is ready to move forward. I will leave it up to the
WGchairs et all. to decide on whether that is another WGLC or IETF LC.

Dropping this document would be a mistake and possibly lead to
implementation mistakes.