Oh, never mind, presumably you're referring to the proposal in this thread.
> On Mar 9, 2021, at 4:47 PM, Carrick Bartle > <cbartle891=40icloud....@dmarc.ietf.org> wrote: > >> The proposal on the table is to deprecate FFDHE. > > Sorry, the title of the document is incorrect and will be changed. The actual > proposal is not to deprecate FFDHE but to deprecate FFDH and prohibit key > reuse for FFDHE. > > >> On Mar 9, 2021, at 1:04 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: >> >> On Tue, Mar 09, 2021 at 11:29:40AM -0800, Carrick Bartle wrote: >> >>>> Because there are still many TLS (non-web) implementations that don't >>>> do ECDHE. >>> >>> I'm confused: if those implementations don't do ECDHE, what's wrong >>> with prohibiting the way it's used? >> >> The proposal on the table is to deprecate FFDHE. If the software stack >> has no ECDHE, and only has FFDHE, it would then have to resort to RSA >> key exchange. >> >>>> * In practice security improves more when you raise the ceiling, >>>> rather the floor. >>> >>> This sort of suggests that we should never deprecate anything, ever, no? >> >> No, rather it suggests that *before* we deprecate, we first work to get >> everyone to use stronger options, and then, crisis situations aside, >> wait for the long tail to effectively peter out. Then deprecate, once >> it is clear that it is mostly a formality. >> >> The difficult question is how to handle situations where the long tail >> is mostly invisible to the IETF community, i.e. happens on isolated >> networks, that use (and may be audited against) our standards, but don't >> show up in Internet surveys, ... It may then be hard to know when to >> declare to declare victory. I don't have a good answer for that. >> This is where Peter Gutmann et. al., may be able to help. >> >> Deprecation is not always easy, and we don't always the desired outcome. >> >> I hear that in Germany operators of some services are expected to >> operate their systems in accordance with "state of the art" practices >> (I guess BCP). This may allow a distinction between "tolerable" and >> "best practice", where things we might deprecate would no longer be >> "best practice", but are still within the standard, and expected >> to interoperate if implemented by both (all relevant) parties. >> >> So short of deprecation, one might say that the legacy algorithms: >> >> * Are not recommended. >> * Can't be expected to be widely implemented >> * Should only be used when the preferred choices >> are not available. >> >> Which is not nearly as strong as "MUST NOT", which is what I take >> deprecation to mean. Am I wrong about the intended meaning of >> "deprecation"? >> >> -- >> Viktor. >> >> _______________________________________________ >> 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
