On Tue, Nov 5, 2024 at 2:09 PM Steve Crocker <st...@shinkuro.com> wrote:
> Nick, > > Thanks. Even if the algorithm is just an encoding format, the same issue > applies: It's important that creating new messages with that algorithm must > stop well before the receivers stop being able to receive messages in that > format. > That's where my knowledge is definitely lacking. What we want to do is minimize the use of RFC7050 in favor of RFC8781. Perhaps that means it is the "Phaseout" stage of the operation? Perhaps it means we need to clarify that this is a data query operation and not necessarily a specific encoding (although the replies clearly need to be in a specific format in order to be interpreted). This is where we need some guidance, I think. I think it is unrealistic to think we can completely remove 7050 use - at least for the foreseeable future - but we definitely want to strongly encourage the proliferation of pref64 as it simplifies migration to v6-only in operationally significant ways. > The point of the proposed life cycle model is that doing this smoothly > takes multiple steps, not just one. After signalling to the community that > an algorithm, encoding choice, etc. needs to be phased out, there needs to > be some way to determine when usage has tailed off before removing the > functionality for processing such messages is removed from the receiving > systems. > > Steve > > > On Tue, Nov 5, 2024 at 2:02 PM Nick Buraglio <burag...@forwardingplane.net> > wrote: > >> 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 >>> >> > > -- > 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
