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, 8 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
Content-Type: text/plain; charset="us-ascii"
Content-ID: <18D26DB9870FD94EB9ADCB427FB31142@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-ID-Hash: 2K7NNP6MABHWOMUNDNELQUSVEONC2IPI
CC: dnsop <dnsop@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_=5BExt=5D_Working_Group_Last_Call_for_draft-ietf?=
 =?utf-8?q?-dnsop-rfc7958bis?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/dnsop/6wJeeczC2_mdsnwyJHVjA1PIEZY>

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=
:
>=20
> 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 ide=
ntify any obvious issues that could arise following the addition of the Pub=
licKey element (implementations appear to key of element/tag names, concern=
s if any, could be memory management with the larger and unused PublicKey C=
DATA). I do not believe versioning is required on the understanding that IA=
NA may revert to the previous version if necessary - there appear to be a f=
ew clients with operational dependencies on the file.
>  Looking ahead to the addition of the PublicKey element, we discussed whe=
ther to publish the PublicKey element for historical TAs and whether we wou=
ld remove the PublicKey for future-historical TAs. While we have not formal=
ized plans, can we assume these are operational decisions to be made by IAN=
A? 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 previous=
ly present?
>    A few editorial comments:
>  The introduction says:
> This document describes the formats and distribution methods of DNSSEC tr=
ust 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 e=
lements of the KeyDigest are the same as the previous trust anchor.
>  I think it can be removed entirely - text regarding duration of use is c=
overed in a prior sentence - and I'm not sure what it adds. My problems wit=
h this are: 1) one does not "change to a trust anchor" following the additi=
on of a (future?) validUntil attribute - it is the same trust anchor; 2) th=
e "it" in "it can change" is difficult to understand, in part because of th=
e 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 i=
s most definitely a DNSKEY element.
>    Section 2.4 Converting to DNSKEY records - A DNSKEY constructed from t=
he KeyDigest will fail to match a published DNSKEY when the REVOKE bit is s=
et - 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 t=
he file does not provide values for DNSKEY protocol or flags - for the purp=
ose of this mechanism, clients can assume valid trust anchors will be for p=
rotocol 3 and that the ZONE and SEP flag bits will be set.
>   Thanks,
> James Mitchell
> Director IANA Technical Services