On Mon, Sep 02, 2024 at 4:01 AM, Petr Špaček <pspa...@isc.org> wrote:
> 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 > Thank you very much for the DNSDIR review, and for following up! > Philosophical questions of what the document is or should do are out of > scope, see > https://mailarchive.ietf.org/arch/msg/dnsop/Lmmz5BoKb5AjMHNfQL1HfXayeJM/ > > Thank you! <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 ...) > > Doh! Yes, it looks like this was missed. Thank you for noticing it — I have not checked the DS's, but yes, these should be fixed… > 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. > Yes, I suspect that this was a threading issue. > 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 ...) > > Yup. I have not double-checked, but yes, this seems to have fallen out accidentally in editing. 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. > ----- > > That seems like a great addition! Authors, please integrate these. Thank you very much! W 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 > >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
