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

[Michael StJohns <[e-mail]>]

On 8/29/2024 4:24 PM, Paul Hoffman wrote:
> On Aug 27, 2024, at 16:46, Warren Kumari<[e-mail]>  wrote:
>> Thank you very much for your comments. We've had some discussions, and the authors will be publishing a new version in the next few days addressing these.
> As you can see, we have turned in -05. We think this deals with the comments from Petr and Mike. In the diff, you can see that we moved all things that said what a relying party who accepts the trust anchor file MUST/SHOULD do to the Security Considerations; this puts them in one place and gives the context for them. We also added some text about how to do the comparison for the two fields (referring to the specific part of RFC 4034 that they need).
>
> Given that this is still in your (Warren's) two hands, not the WG's many hands, let us know if you need any more changes before the assigned telegchat.
>
> --Paul Hoffman (for the authors)
>
> _______________________________________________
> DNSOP mailing list [e-mail]
> To unsubscribe send an email [e-mail]

Hi -

Took a brief look at -05.  Still problems unaddressed.  Section 2.2 6th 
paragraph:

>     The validFrom and validUntil attributes in the KeyDigest element
>     specify the range of times that the KeyDigest element can be used as
>     a trust anchor.

"can be used as a trust anchor" is problematic as it appears to be 
directive on the recipient.   As I've said - now at least three times - 
please change this language so it represents what the IANA is doing, not 
what the recipient should do.  Among other things, specifying a 
"validUntil" date on a trust anchor and then NOT ceasing to use that 
trust anchor and not "replacing" it is problematic.

Instead replace this paragraph with:

"The validFrom attribute in the KeyDigest element indicates the first 
planned date that the IANA intends to start signing the root DNSKEY 
RRSet with this key.  Likewise, the validUntil attribute indicates the 
last planned date of such signing.  However, these are for planning 
purposes only and relying parties should not automatically invoke a 
state change on a trust anchor based on these dates as operational 
considerations may result in a delay past these dates."

Section 4 - nit - generally we don't have single entry subsections.

Delete section 4.1.1 - continues to be a problem if IANA fails to 
supercede a trust anchor on the planned schedule. It is directive on the 
relying party in a way that could cause operational difficulties - to 
wit - iana actually continuing to sign with the set of trust anchors 
past their validUntil dates.  There is also no such thing as "change to 
a trust anchor" in DNSSEC.  All trust anchors are equally valid until 
revoked or removed.

Delete the third paragraph of section 5.

In section 5, replace the first sentence with:

"The intent is for the IANA to publish trust anchors using this format 
at least <6> months before the first use of a new trust anchor.  The 
intent is also that the published document will include all DNSSEC trust 
anchors for the root zone that are currently under management (e.g. 
generated and loaded for use within a key signing ceremony but not 
revoked) by the IANA at the time of publication."

Second paragraph - lower case the "may" - people are mostly not protocol 
elements, although the DNS crowd seems to think so. Also, add "Also for 
operational reasons, IANA may delay taking any trust anchor key out of 
service past the dates indicated in the most recent publication of the 
trust anchor file."

Please - can we avoid moving the deck chairs around again without 
actually fixing anything?

Thanks - Mike