Re: [DNSOP] [Ext] Benjamin Kaduk's No Objection on draft-ietf-dnsop-dnssec-iana-cons-04: (with COMMENT)

Paul Hoffman <paul.hoffman@icann.org> Wed, 06 October 2021 17:16 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 B39DD3A05AA; Wed, 6 Oct 2021 10:16:48 -0700 (PDT)
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 efSxjEADv1ws; Wed, 6 Oct 2021 10:16:42 -0700 (PDT)
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 99FE13A0637; Wed, 6 Oct 2021 10:16:42 -0700 (PDT)
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.43/8.16.0.43) with ESMTPS id 196HGefU008488 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Oct 2021 17:16:40 GMT
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 Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.13; Wed, 6 Oct 2021 10:16:39 -0700
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.0922.013; Wed, 6 Oct 2021 10:16:39 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, dnsop <dnsop@ietf.org>
Thread-Topic: [Ext] Benjamin Kaduk's No Objection on draft-ietf-dnsop-dnssec-iana-cons-04: (with COMMENT)
Thread-Index: AQHXuh16FCKnS+n06Eid5IvMv23EYqvGrPUA
Date: Wed, 06 Oct 2021 17:16:39 +0000
Message-ID: <8D26A6FE-FF61-420A-9ECA-9F8215F3FE9B@icann.org>
References: <163346136647.16562.1942469170763159709@ietfa.amsl.com>
In-Reply-To: <163346136647.16562.1942469170763159709@ietfa.amsl.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=_B4107980-D7F7-42C0-8178-9137C5314E49"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-10-06_04:2021-10-06, 2021-10-06 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/j_XhFO73XXchgRnbW7TcKo-dJaw>
Subject: Re: [DNSOP] [Ext] Benjamin Kaduk's No Objection on draft-ietf-dnsop-dnssec-iana-cons-04: (with COMMENT)
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, 06 Oct 2021 17:16:49 -0000

On Oct 5, 2021, at 12:16 PM, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks to Dan Harkins for the secdir review, and the authors for the
> corresponding updates.
> 
> Section 1
> 
>   DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035].
>   DNSSEC commonly uses two resource records beyond those defined in RFC
>   4034: DS [RFC3658] (which was obsoleted by RFC 4034) and NSEC3
>   [RFC5155].
> 
> I'm a bit confused at how DS is "beyond those defined in RFC 4034" when
> RFC 4034 includes discussion of DS, the record format, etc.

Thank you; no one else noticed this. I've replaced it with:
DNSSEC is primarily described in {{RFC4033}}, {{RFC4034}}, and {{RFC4035}}.
DNSSEC commonly uses another resource record beyond those defined in RFC 4034:
NSEC3 {{RFC5155}}.
DS resrouce records were originally defined in {{RFC3658}}, and that definition
was obsoleted by RFC 4034.


> Section 4
> 
>   In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3)
>   Parameters" registry, the registration procedure for "DNSSEC NSEC3
>   Flags", "DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags"
>   are changed from "Standards Action" to "RFC Required".
> 
> I note (this is a "comment", after all, right?) that the "flags"
> registries have only 7 values available.  It is not entirely clear to me
> that the IESG would be justified in using an RFC 5742 conflict-review
> response to try to block any frivolous registration attempts made in
> non-IETF-stream RFCs, but maybe we are willing to place confidence in
> the other streams' managers behaving responsibly and otherwise accept
> this risk.

I think so, yes.

> 
> NITS
> 
> Section 2 only talks about "DS or NSEC3 hash algorithms" but the actual
> registry actions also cover the NSEC3{,PARAMS} flags registries.

Good catch. I'll update that sentence to talk about all the registries.

--Paul Hoffman