Thanks for the reply, Steve. On Tue, Nov 5, 2024 at 12:26 PM Steve Crocker <st...@shinkuro.com> wrote:
> Folks, > > Thanks very much for considering > > Documenting and Managing DNSSEC Algorithm Lifecycles > draft-crocker-dnsop-dnssec-algorithm-lifecycle-01 > > For reference, I was motivated to propose this when I understood how the > Red Hat incident evolved. For those who haven't followed that incident, > Red Hat removed an algorithm from the library, but messages with that > algorithm continued to arrive, causing a bit of chaos. > > I noted during the DNSOP session yesterday that two algorithms were > selected for deprecation. I believe the message below pertains to one of > them. As noted in the life cycle document, the process of downgrading the > use of an algorithm should go through three(!) phases. As described in the > I-D, a sequence of three actions is described: Phaseout, Deprecation, > Obsolescence. > (Feel free to propose alternative words that are grammatically parallel.). > The text is quoted below. > > Questions for the DNSOP WG re moving an algorithm to "deprecate" status: > > 1. Does moving an algorithm to "deprecate" state exactly match any of > the actions listed in the lifecycle draft? If so, which one? If not, why > not? > > 2. Is there a plan or process for taking the other actions? > > As Jen stated, there is not really a cryptographic algorithm in play, per se. However, once this was published I second guessed the term "depreciation" since I think that what we really want to do is encourage pref64 over 7050 behavior. I think we can probably come up with some more fitting language. I personally akin to the phrase "Encourage use of pref64 over RFC7050/DNS64/DNS for IPv6-only prefix discovery", or something similar. Depending on tone, we could also say "discourage"; I tend to lean to the positive over the negative, but whatever the group thinks is ok with me. A question for the group: Would adjusting the term "depreciation" to something less rigid be more desirable? > Thanks, > > Steve > > > D. Phaseout > > * Prerequisites: > > - Cryptographic community has determined the algorithm is > reaching its end of life. > > * IETF determines it is time to announce the phaseout. > > * Action: IETF publishes notice to signing operators to transition > away from the algorithm and begin signing with a mainstream > algorithm. > > E. Deprecation > > * Prerequisites: > > - Measure signing activity. > > - Signing activity is deemed to have largely subsided. > > * IETF determines it is time to deprecate the algorithm for use with > DNSSEC. > > * Action: IETF publishes notice that use of the algorithm is now > inappropriate for DNSSEC signing. > > F. Obsolescence > > * Prerequisite: Measurement of signing is at the lowest achievable > level. > > * IETF determines the algorithm is obsolete. > > * Action: IETF publishes notice that [the] algorithm is obsolete and > ought [to] be removed from implementations. > > > ---------- Forwarded message --------- > From: IETF Secretariat <ietf-secretariat-re...@ietf.org> > Date: Mon, Nov 4, 2024 at 7:00 PM > Subject: [DNSOP] The DNSOP WG has placed draft-buraglio-deprecate7050 in > state "Candidate for WG Adoption" > To: <dnsop-cha...@ietf.org>, <dnsop@ietf.org>, < > draft-buraglio-deprecate7...@ietf.org> > > > > The DNSOP WG has placed draft-buraglio-deprecate7050 in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-buraglio-deprecate7050/ > > > _______________________________________________ > 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 >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org