Telechat Review of draft-ietf-dnsop-rfc7958bis-05
review-ietf-dnsop-rfc7958bis-05-dnsdir-telechat-spacek-2024-09-02-00

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