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

[Warren Kumari <[e-mail]>]

On Thu, Aug 29, 2024 at 6:21 PM, Michael StJohns <[e-mail]>
wrote:

> On 8/29/2024 4:24 PM, Paul Hoffman wrote:
>
> On Aug 27, 2024, at 16:46, Warren Kumari <[e-mail]> <[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 to [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."
>


Yes, you have stated this multiple times; however, I believe you are in the
rough. The IANA has reviewed this text (which is identical in the original
RFC, RF7958), and the validUntil is intended to mean exactly what it
says:  the material is validUntil then, and is not intended to be used
after that. Yes, this does mean that the IANA has to publish new keys
before then, and it is an error if they don't. This is just like any other
trust anchor — e.g my machine ships with a "Baltimore CyberTrust Root" cert
in the trust store, which is Not Valid After Monday, May 12, 2025 at
7:59:00 PM Eastern Daylight Time. This is when it stops being valid, not
necessarily when they hope to have replaced it by…

Yes, I might *personally* decide to use the IANA TA after the validUntil if
they haven't published a new one. If I did, that would be entirely my own
(bad) decision, and I'm clearly doing something unsupported… just like if I
happen to eat a can of beans past their expiration date…


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.
>


As above -- the validUntil is not the planned schedule; it is when the key
is validUntil.


> 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."
>

Your suggested text is attempting to specify IANA policy / telling IANA how
they should be running and managing the trust anchor. This is not the
document to do it in, nor is this the list to do it on — that's the
[e-mail] mailing list.

I understand that you don't like this document; however, I believe you are
in the rough. The document went through WGLC and IETF LC, and was reviewed
by the IANA. Petr identified issues which he clearly documented in a polite
and helpful manner, and these were addressed, and the changes confirmed
with the WG. I'm not seeing support for your interpretation, nor do I think
that the larger changes are in scope for this document or the IETF.


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

I believe that the authors are attempting to do what the WG, IETF, IANA and
myself have requested, and I think that the above tone was neither helpful
nor necessary.

W

Thanks - Mike
>
>
>
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>