Re: [saag] AD review of draft-iab-crypto-alg-agility-06

[Peter Gutmann <[e-mail]>]

Viktor Dukhovni <[e-mail]> writes:

>    * Remove from use by default.
>    * Reduce relative preference.
>    * Require non-default compile-time options to enable.
>    * Remove the code.

That's more or less what I use, specifially, "make the option least-
preferred", then "require a custom compile", then "remove the code", with an
occasional "reinsert the &*)(($)@ code because some widely-used app is still
living 15 years in the past".

The problem with trying to handle backwards-compatibility is that the long
tail never actually reaches zero but instead tends toward some (non-zero)
constant of users who will never upgrade if they're not forced to.  This is
why you can't maintain backwards-compatibility for ever, some users have to be
forced to upgrade.  What I typically do is make something a compile-time
option that's not enabled in any standard build, so they have the option to
enable the deprecated behaviour at the expense of building and distributing
custom binaries to do so.  Suddenly the absolutely-impossible-can-never-be-
done upgrade magically becomes possible, because the cost of not upgrading has
become nonzero.  The trick is figuring out how nonzero to make it, and on
which time schedule.

Peter.