From: Paul Hoffman <paul.hoffman@icann.org>
To: John R Levine <johnl@taugh.com>
Thread-Topic: [Ext] [DNSOP] Re: Working Group Last Call for
 draft-ietf-dnsop-rfc7958bis
Thread-Index: AQHayz1kIj9EWBf6FESgVX+wqt6mW7HtopyA
Date: Mon, 8 Jul 2024 18:08:45 +0000
Message-ID: <FA9FC0A4-1103-4464-9E19-86B36FE27DD4@icann.org>
References: 
 <CADyWQ+EGh2N8tssBRskH=PVXV1e1eON4z=8E1JWPypNUyZVwLg@mail.gmail.com>
 <879F4E56-9939-4C57-A597-9BB113F92C0D@iana.org>
 <E58B1C4D-1DB0-4123-9C91-02E7FDC6D6EB@icann.org>
 <0bc64fd0-0031-4ca2-b722-ad0d585ea686@taugh.com>
In-Reply-To: <0bc64fd0-0031-4ca2-b722-ad0d585ea686@taugh.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <FC2EA41EB3C6A649BDBD4434DE4E9F7D@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-ID-Hash: T5ILCDX3SRDQUSX54JLCRYYO3UYDBWNI
CC: dnsop <dnsop@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_=5BExt=5D_Re=3A_Working_Group_Last_Call_for_draf?=
 =?utf-8?q?t-ietf-dnsop-rfc7958bis?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/dnsop/lJoBcA2wyssBje-DZ97GNkWRY8Y>

Thanks for the comments. They are all addressed in the revised draft coming=
 out shortly.

--Paul Hoffman

On Jun 30, 2024, at 15:31, John R Levine <johnl@taugh.com> wrote:
>=20
> I took a look and didn't find anything particularly troubling.  I agree t=
hat adding the new optional DNSKEY element doesn't need a version number. G=
etting rid of private certificates in favor of a CA signed cert for the HTT=
PS server makes sense.
>=20
> On the other hand, I don't understand what the point of the new optional =
DNSKEY field in the XML is.  I see that IANA does not currently include it.
>=20
> It's always been possible to retrieve the DNSKEY records from the live ro=
ot and check that one of them matches the digest in the XML.  Is this to pr=
ovide a way to remember the old DNSKEYs that have been rotated out of the r=
oot?  A sentence or two describing the motivation would help.
>=20
> The third paragraph of section 3.2 describes a detached CMS signature. Wh=
ile I realize it's there in 7958, I don't see how it provides any security =
at all.  It's signed with an ICANN private key but there's no way I can see=
 to tell the "real" ICANN CA from one that I just made up to sign my fake X=
ML.  The useful security is the accredited CA signed HTTPS certificate desc=
ribed in the following paragraph, so I'd take the CMS signature out or at l=
east note that it's trivial to defeat unless you have external knowledge ab=
out ICANN's private CA.
>=20
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY