On Tue, Mar 9, 2021 at 1:05 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.
Depreciation is how you get the laggards to replace things. Depreciation leads, not tails, replacement. Because we depreciated RC4, PCI stopped being silly about mandating its uses. Had we not done this, they would have continued as is. > > 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. This was already done via the UTA working group. > > 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. That is depreciation. > > 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"? There is no protocol police. To the extent that industries want to ensure that systems are secure, they have to ensure updates for the life of the system. I think it's reasonable to require implementation and deployment of 12 year old standards. Sincerely, Watson Ladd > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
