[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

[Paul Hoffman <[e-mail]>]

On Aug 9, 2024, at 12:16, Michael StJohns <[e-mail]> wrote:
> 
> Two comments - one major and one very minor.
> 
> Major:  I'm sorry for the late comment, but I didn't realize you were planning on starting to provide prospective DS's for unpublished keys.  Telling people there's a new trust anchor, and that the live key matches this file is one thing - easy enough for a relying party to match up a few things and accept the TA update.  Telling them there's an unpublished key and "trust me, when you see it it will have this digest and you should go ahead now and install it in your trust anchors" seems to be a bit more risky.

This is unchanged from RFC 7958, published in 2016. It was done for the key rollover to KSK-2017. If you propose to change this activity now, I propose that you take this to IANA; the current draft and RFC 7958 reflect IANA's long-established policies.

> Looking at the Security Considerations - I don't think the updates to this section made this is sufficiently evident.

That's because this part of RFC 7958 was not updated in this draft.

>   I'd suggest two things:  1) Talk about the above in the security considerations, and 2) Place a disclaimer in the TA file with similar language about the prospective key material.

The latter is a suggestion to IANA.

> Minor minor minor nit - feel free to ignore this:
> 
> The flags field for the DNSKEY is represented in most DNS presentation modes as an unsigned decimal integer - but it's actually a bit field of two bytes.  The representation is used mostly because that's what a DNS Zone File used (e.g. either Base64 or a decimal integer) for most non-text fields.  Unclear decimal should be used for XML.

Section 2.2 of RFC 4034 says "The Flag field MUST be represented as an unsigned decimal integer."

> It may make some sense here to use <xsd:hexBinary { length = 2 }/>  is the field type the appropriate mapping here  - <Flag>0101</Flag> instead of the decimal 257.  Easier to see what bits have been set.

That would then be different than the KeyType, Algorithm, and DigestType fields that are expressed as xsd:nonNegativeInteger. If the WG wants to make this inconsistent, it can, but I would generally be against that.

--Paul Hoffman