> 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"?
That's my understanding as well. > 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
