Paul and Tim, Thanks for your comments. This submission was triggered by the Red Hat snafu. Red Hat removed an algorithm from the library when they determined it should not be used. However, as their users discovered quickly, messages signed with that algorithm continued to arrive, with consequent disruption of their operation.
It seemed obvious to me that removal of an algorithm from services should be done carefully. Validation should continue to be available long after the new signing is quenched. I assumed there would be fairly explicit advice along this line somewhere in the RFCs. RFC 8624 gave the status of various algorithms, but it did advise how to introduce and how to remove an algorithm in coordination with other algorithms. I thought about it afresh and described the seven phases. I then sought help/comment/etc from Russ Housley. Meanwhile, Wes Hardaker and Warren Kumari were working on RFC 8624-bis. We had some substantive and civilized exchange. At the risk of speaking for them, I understand they want to have a way to record the current status of an algorithm, and they wanted to distinguish implementation vs use for both signing and validation. In our judgment, this is fine but doesn't tell those operators looking for operational advice re the steps are in a lifecycle. In the Red Hat situation, they skipped from phase 5 to phase 7 without spending time in phase 6. Regarding the number of RFCs needed to step each algorithm through its phases, this feels to me the wrong issue to focus on. The criteria and decision process to move from one phase to the next are substantive. I'm agnostic regarding whether each phase change requires a fresh RFC or some other process involving expert advice that updates the tables. In any case, we're talking about six transitions over the life of the algorithm. Algorithm lifetimes are on the order of twenty years, and we're likely only dealing with a half dozen algorithms or so. Returning to the main point, it seems to me there should be crisp, credible advice to operators altering them that multiple steps are required to properly phase in and phase out an algorithm. Thanks, Steve On Sat, Oct 5, 2024 at 2:07 PM Tim Wicinski <tjw.i...@gmail.com> wrote: > > As an operator, I feel the implementers should have a strong say in this. > They have business decisions based on what customers wish to have > supported, and while they can guide customers, they need to think of the > long tail. > (I worked for a software company that supported Internet Explorer 6 into > the 2010s, because of large contracts). > > > As a chair, the current draft appears to require seven RFCs for the > lifecycle of an algorithm. > I agree with Paul W that the WG should spend their time on other > documents, but am happy to be proven wrong. > > I do believe the 8624bis authors and the WG are open to updating > the values for the table > > https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml > > that seems like a starting point > > tim > > > On Fri, Oct 4, 2024 at 10:40 PM Paul Wouters <p...@nohats.ca> wrote: > >> >> > >> > On Oct 4, 2024, at 15:28, Russ Housley <hous...@vigilsec.com> wrote: >> > >> > This document is related to draft-ietf-dnsop-rfc8624-bis. We ask the >> DSNOP WG to adopt it. >> >> The document seems like a theoretical ideal of an algorithm life cycle. >> There have been many kind of considerations in play that have determined >> the algorithm and key sizes of algorithms. There have been good strong >> discussions in many venues inside and outside IETF. I don’t think this >> document would add any value to those discussions, such as those happening >> recently on RFC8624bis or the sha1 deprecation documents. >> >> I would rather see the WG spend their time on other documents. >> >> Paul >> _______________________________________________ >> 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 > -- Sent by a Verified [image: Sent by a Verified sender] <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y> sender
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
