I'm not sure such an implicit approach best serves everyone's interests... Vendors would be better served if we explicit communicate expected timelines for deprecation, and expected timelines where maintaining support is a "must"/MUST/SHOULD. And this WG would be better served if we have explicitly communicated such timelines, since then deprecation is straightforward, instead of the current situation where we need to have discussions such as the current one.
But I think having this discussion in this thread makes it hard to have the discussion around FFDHE. Let me bring up this point in a separate thread later, after the dust around FFDHE has settled :-) best, Nimrod On Fri, 16 Dec 2022 at 18:49, Russ Housley <hous...@vigilsec.com> wrote: > There have been attempts in the past to signal this to product planners: > > SHOULD+ This term means the same as SHOULD. However, it is likely > that an algorithm marked as SHOULD+ will be promoted at > some future time to be a MUST. > > SHOULD- This term means the same as SHOULD. However, an algorithm > marked as SHOULD- may be deprecated to a MAY in a future > version of this document. > > MUST- This term means the same as MUST. However, we expect at > some point that this algorithm will no longer be a MUST in > a future document. Although its status will be determined > at a later time, it is reasonable to expect that if a > future revision of a document alters the status of a MUST- > algorithm, it will remain at least a SHOULD or a SHOULD-. > > Russ > > On Dec 16, 2022, at 11:27 AM, Nimrod Aviram <nimrod.avi...@gmail.com> > wrote: > > > There needs to be some plan with a schedule that gives downstream users > time to get their act in gear. > I agree. And the schedule should also allow for deprecation in a > reasonable timeline. > > > Should there be an IETF group to help coordinate things like this? > I think it'd be better if each group coordinates this for itself. > We should do this, if we can. I would suggest "Intent to Deprecate" > documents that e.g. make it clear that you cannot count on TLS 1.2 only in, > say, 2030. Otherwise we'll have the same conversation around that > deprecation then. > > Is there interest in this? > > > > On Fri, 16 Dec 2022 at 09:41, Hal Murray <halmurray+...@sonic.net> wrote: > >> >> say...@gmail.com said: >> > For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just >> > endlessly keeping old cipher suites alive. The unwise cost-cutting in >> those >> > areas does not constrain the rest of the internet. >> >> Agreeded, but the software maintainers can't just drop support for X >> because >> it has been deprecated. There needs to be some plan with a schedule that >> gives downstream users time to get their act in gear. >> >> Should there be an IETF group to help coordinate things like this? If >> nothing >> else, there should be a RFC explaining the problem to vendors planning to >> ship >> software that can't be updated -- and showing their potential customers >> what >> to consider. >> Maybe data sheets should list the RFCs they depend upon -- with a big >> red >> arrow nwxt to the ones that have been obsoleted or deprecated. >> >> IoT and embedded are not the only problems. There are many companies >> that run >> old stable software. Ubuntu supports LTS releases for 5 years with 5 >> more >> available for a fee. >> https://ubuntu.com/about/release-cycle >> Do we have to worry about this area? Or will the companies like Ubuntu >> take >> care of their customers? >> >> >> >> >> -- >> These are my opinions. I hate spam. >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
