Reviewer: Petr Špaček
Review result: Ready with Issues
I was assigned as the dnsdir reviewer for draft-ietf-dnsop-rfc7958bis-05.
For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir
Philosophical questions of what the document is or should do are out of
scope, see
https://mailarchive.ietf.org/arch/msg/dnsop/Lmmz5BoKb5AjMHNfQL1HfXayeJM/
The most visible change in -05 is moving paragraphs to Security
Considerations. The result reads better than -04.
Version -05 introduced a _new_ problem:
In section 2.3. XML Example the <KeyDigest id="Kmyv6jo"> was added to
the XML _but_ this change was NOT reflected in the paragraph following
the XML. It starts with text "The DS record derived from this example
would be:".
Either a DS RR is missing, or the text needs to specify a timestamp
which is before validFrom for the newly added key. I think an explicit
timestamp is in order anyway.
To make things faster here is a proposal with fixed text:
-----
DS records derived from this XML example on 2024-08-01 would be:
. IN DS 20326 8 2
E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
. IN DS 38696 8 2
683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
-----
(Someone please double-check ...)
Because -05 contains a factual problem and needs an update anyway I'm
going to remind authors that -06 is an opportunity to fix other trouble
pointed out in review of -04.
It's unclear why -05 did not react to some of the previous review
comments related to examples in -04. Given the lack of an explicit
answer I'm going to assume it's omission caused by confusing threading.
The only point I'm going to reiterate is
https://mailarchive.ietf.org/arch/msg/dnsop/rbOyxQ5JCZCOQ5lj3TsFHqTnUbQ/
- the point marked as "C.", further explained in
https://mailarchive.ietf.org/arch/msg/dnsop/RXdry2-vzn7uvV1V6i17AjKapJ0/
TL;DR version: DNSKEY example is really missing, along with suitable
Security Considerations! The DNSKEY example was already present in -03
but got lost in -04. I don't understand why.
To expedite things here is a proposal how to fill in the missing bits of
text here. Hopefully it will not fall through cracks between -05 and -06:
... to be put after "DS records derived from this XML example on"
paragraph in 2.3 XML Example ...
-----
DNSKEY record derived from this XML example on 2024-08-01 would be:
. IN DNSKEY 257 3 8
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=
Please note the inconsistency between DS and DNSKEY sets above. DNSKEY
record for KSK-2024 cannot be reconstructed from KeyDigest element
id=Kmyv6jo because it does not contain the optional publickeyinfo element.
-----
(Someone please double-check ...)
This extended 2.3 XML Example should be complemented by an additional
paragraph in Security Considerations. Something like:
-----
Relying parties which depend on the optional publickeyinfo element are
at risk of not seeing TAs published without this optional element.
Consequently different parties who ingest the same XML at the same time
can produce different set of trust anchors.
-----
I assume authors consider this property of the XML format acceptable. I
personally don't like it, but if everyone else is okay with it I will
not press further for mandatory publickeyinfo element.
--
Petr Špaček
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
