On Thu, Aug 29, 2024 at 6:21 PM, Michael StJohns <m...@nthpermutation.com> wrote:
> On 8/29/2024 4:24 PM, Paul Hoffman wrote: > > On Aug 27, 2024, at 16:46, Warren Kumari <war...@kumari.net> > <war...@kumari.net> 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 -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org > > 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 ksk-rollo...@icann.org 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 -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
