[DNSOP] Re: [Ext] Working Group Last Call for draft-ietf-dnsop-rfc7958bis
Paul Hoffman <paul.hoffman@icann.org> Mon, 08 July 2024 18:08 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 0D2D7C1E590E for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2024 11:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5Ie1-aP47Am for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2024 11:08:52 -0700 (PDT)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 0F266C1F6C94 for <dnsop@ietf.org>; Mon, 8 Jul 2024 11:08:43 -0700 (PDT)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa2.lax.icann.org (8.18.1.2/8.18.1.2) with ESMTPS id 468I8ga1022830 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dnsop@ietf.org>; Mon, 8 Jul 2024 18:08:42 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.1258.34; Mon, 8 Jul 2024 11:08:41 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) by MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) with mapi id 15.02.1258.034; Mon, 8 Jul 2024 11:08:41 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: James Mitchell <james.mitchell@iana.org>
Thread-Topic: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-rfc7958bis
Thread-Index: AQHa0WHcaQLIb4UUdUKxOHnKFX7uJQ==
Date: Mon, 08 Jul 2024 18:08:41 +0000
Message-ID: <A8A97850-6AF6-4780-96ED-E65B5BE70782@icann.org>
References: <CADyWQ+EGh2N8tssBRskH=PVXV1e1eON4z=8E1JWPypNUyZVwLg@mail.gmail.com> <879F4E56-9939-4C57-A597-9BB113F92C0D@iana.org>
In-Reply-To: <879F4E56-9939-4C57-A597-9BB113F92C0D@iana.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <18D26DB9870FD94EB9ADCB427FB31142@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-07-08_09,2024-07-05_01,2024-05-17_01
Message-ID-Hash: 2K7NNP6MABHWOMUNDNELQUSVEONC2IPI
X-Message-ID-Hash: 2K7NNP6MABHWOMUNDNELQUSVEONC2IPI
X-MailFrom: paul.hoffman@icann.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: [Ext] Working Group Last Call for draft-ietf-dnsop-rfc7958bis
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6wJeeczC2_mdsnwyJHVjA1PIEZY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>
Thanks for the comments. They are all addressed in the revised draft coming out shortly. --Paul Hoffman > On Jun 26, 2024, at 13:31, James Mitchell <james.mitchell@iana.org> wrote: > > All, > Please find my comments below. > The draft introduces a new optional field PublicKey without providing a versioning mechanism - both current and new formats are retrieved from the same path. I have reviewed a few publicly available parsers and did not identify any obvious issues that could arise following the addition of the PublicKey element (implementations appear to key of element/tag names, concerns if any, could be memory management with the larger and unused PublicKey CDATA). I do not believe versioning is required on the understanding that IANA may revert to the previous version if necessary - there appear to be a few clients with operational dependencies on the file. > Looking ahead to the addition of the PublicKey element, we discussed whether to publish the PublicKey element for historical TAs and whether we would remove the PublicKey for future-historical TAs. While we have not formalized plans, can we assume these are operational decisions to be made by IANA? If so, does the draft require text to clarify that the PublicKey may be present for some KeyDigests and that the element may be removed if previously present? > A few editorial comments: > The introduction says: > This document describes the formats and distribution methods of DNSSEC trust anchors that have been used by IANA for the root zone of the DNS since 2010. > This is not quite true given a format with the publicKey element was not possible back in 2010. > The following sentence is difficult to read: > If the relying party is using a trust anchor that has a KeyDigest element that does not have a validUntil attribute, it can change to a trust anchor with a KeyDigest element that does have a validUntil attribute, as long as that trust anchor's validUntil attribute is in the future and the DNSKEY elements of the KeyDigest are the same as the previous trust anchor. > I think it can be removed entirely - text regarding duration of use is covered in a prior sentence - and I'm not sure what it adds. My problems with this are: 1) one does not "change to a trust anchor" following the addition of a (future?) validUntil attribute - it is the same trust anchor; 2) the "it" in "it can change" is difficult to understand, in part because of the prior issue and because it is the validUntil that is changing; 3) DNSKEY elements is not defined - it should not be the (optional) PublicKey which is most definitely a DNSKEY element. > Section 2.4 Converting to DNSKEY records - A DNSKEY constructed from the KeyDigest will fail to match a published DNSKEY when the REVOKE bit is set - this doesn't create an issue for this protocol but may cause confusion during a rollover. It might be clearer to say something to the effect of the file does not provide values for DNSKEY protocol or flags - for the purpose of this mechanism, clients can assume valid trust anchors will be for protocol 3 and that the ZONE and SEP flag bits will be set. > Thanks, > James Mitchell > Director IANA Technical Services
- [DNSOP] Working Group Last Call for draft-ietf-dn… Tim Wicinski
- [DNSOP] Re: [Ext] Working Group Last Call for dra… James Mitchell
- [DNSOP] Re: Working Group Last Call for draft-iet… Tim Wicinski
- [DNSOP] Re: [Ext] Working Group Last Call for dra… Paul Hoffman
- [DNSOP] Re: Working Group Last Call for draft-iet… John R Levine
- [DNSOP] Re: Working Group Last Call for draft-iet… Florian Obser
- [DNSOP] Re: Working Group Last Call for draft-iet… Peter Thomassen
- [DNSOP] Re: Working Group Last Call for draft-iet… Ben Schwartz
- [DNSOP] Re: [Ext] Re: Working Group Last Call for… Paul Hoffman
- [DNSOP] Re: [Ext] Working Group Last Call for dra… Paul Hoffman
- [DNSOP] Re: [Ext] Re: Working Group Last Call for… Paul Hoffman
- [DNSOP] Re: Working Group Last Call for draft-iet… Tim Wicinski
- [DNSOP] Re: [Ext] Re: Working Group Last Call for… Peter Thomassen
- [DNSOP] Re: [Ext] Re: Working Group Last Call for… Paul Hoffman
- [DNSOP] Re: [Ext] Re: Working Group Last Call for… Paul Hoffman