[openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Matt Caswell]

On 16/11/15 15:51, Emilia Käsper wrote:
> Thanks all for your feedback!
> 
> I asked for mainstream use-cases for algorithms whose removal could
> cause widespread pain. Some individual users, undoubtedly, will be hit
> by this, and I acknowledge that they may not be reading this list. But I
> wanted to know if I'd missed something endemic. I also asked elsewhere:
> Adam Langley pointed me to the MD4 use-case and Steve confirmed that RC2
> must stay.
> 
> There is a tradeoff: by attempting to accommodate every single use-case,
> we will weaken the library for a substantial amount of our user base, by
> offering them bad defaults, or simply by virtue of the fact that our
> developer resources are not infinite. (Near)-dead code is a liability.

We can significantly reduce that liability by removing any assembler
optimisations. Also just because something is available doesn't mean it
has to be "default". We can have good defaults whilst keeping old crypto.


> 
> So far, excluding suspicions that something may be used somewhere, I've
> received one clear argument, for RC5. And, while I'm sympathetic to the
> cause, I believe this is the case where we have to balance one user's
> needs against everyone else's.
> 
> As for specific deprecation strategies:
> - Don't forget that all applications will have to recompile against 1.1.
> 
> - Disabling algorithms doesn't work well for us as it's just pushing the
> decision on the distros. It also wouldn't win us any resources as we'd
> still be responsible for keeping the code bug-free. The only win would
> be in default compiled code size.

Disabling algorithms isn't the right answer IMO. I do like the idea of a
"liblegacycrypto". That way people that only have need of current
up-to-date crypto can stick with the main library. Others who need the
older crypto can still get at it. Yes, that means we still have to
maintain this code - but I don't see it as that big a burden.

> 
> - We can leave OPENSSL_NO_XXX defines around so wrapper libraries
> (Python, PHP etc) who correctly account for the fact that an
> implementation may be missing (which they have to, anyway) will continue
> to work.
> 
> - Removing assembly support is a GREAT suggestion to simplify the
> complexity, and I think we should do this for anything we end up leaving
> in, and perhaps even for some things not yet on the hit list (RC4?).
> 
> - I appreciate OpenSSL's role as a "Swiss army knife" research tool but
> research needs shouldn't prevail over those of real applications. We are
> generally not on the frontline of deprecating things - RC4 isn't yet on
> the list. SSLv3 isn't yet on the list, etc. But we can't become the
> Internet Archive of All Old Crypto either, and there's some cleanup to
> do that's long overdue.

Being the "swiss army knife" is no bad thing (even where that includes
old crypto). We just have to find a way to separate the two concerns:
current crypto (and only current crypto) for most (and probably most
importantly for libssl users); broader crypto support for those that
want it (which is why I like the liblegacycrypto idea because it enables
us to do that).


> It seems to me that these can pretty safely go:
> 
> MD2 - (The argument that someone somewhere may want to keep verifying
> old MD2 signatures on self-signed certs doesn't seem like a compelling
> enough reason to me. It's been disabled by default since OpenSSL 1.0.0.)
> MDC2
> SEED
> RC5 

All candidates for liblegacycrypto IMO rather than deletion.

Whether this is the right thing to do in the 1.1.0 timeframe is another
consideration though. Viktor's arguments are quite convincing.

Matt