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

[Tomas Mraz]

On Čt, 2015-11-19 at 02:12 +0000, Viktor Dukhovni wrote:
> On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote:
> 
> > > No, of course not. But after letting people depend on this “single
> > > cryptographic library” for many years, telling them “too bad” isn’t very
> > > nice.
> > 
> > I guess I'm just having a hard time wrapping my head around why, upon
> > hearing that the volunteer-run project is giving years' advance notice
> > that certain features will be removed, the response is insistence that
> > everything must remain supported forever, instead of using the advance
> > notice to investigate alternatives.  Volunteers should be allowed to
> > ease up when they need to, after all.
> 
> Culture-clash.  Security culture says everything remotely weak must
> go, but release-engineering culture emphasizes compatibilty.  The
> crypto library is more of a systems component, not a security
> component.  The SSL library is more of a security component than
> a systems component, and has algorithm negotiation.

What about some reasonable middle ground?
1. remove all assembler implementations of not-current crypto
2. remove all references of it from the libssl
3. remove the respective EVP_add_cipher(), EVP_add_digest(),... from the
OpenSSL_add* functions so the users have to explicitly add these to use
them automatically.
This way it is ensured that normal signature validation does not allow
for these obsolete hashes to be used, etc.
It is questionable whether it would be also good idea to disable the
active operations - i.e. encryption for legacy ciphers and signature
creation for legacy combinations of signing algorithms and hashes.

In future it might be even reasonable to move the implementations into
the libcryptolegacy.so however I am not sure this change is worth it for
1.1.0. 

I believe the maintenance costs for pure C implementations in such
separate libcryptolegacy or even in the main C library would be quite
minimal. I would also expect the users of such legacy code to step up
with sharing the maintenance costs.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)