Re: [TLS] consensus call: deprecate all FFDHE cipher suites

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.aviram@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+tls@sonic.net <mailto:halmurray%2Btls@sonic.net>> wrote:
> 
> sayrer@gmail.com <mailto:sayrer@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 <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 <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls