but it did NOT advise how to introduce and how to remove an algorithm in coordination with other algorithms.
On Sat, Oct 5, 2024 at 2:31 PM Steve Crocker <st...@shinkuro.com> wrote: > 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 > -- 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
