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

[Viktor Dukhovni]

On Fri, Nov 13, 2015 at 10:02:02PM +0000, Salz, Rich wrote:

> > So I'm trying to help move forward, without creating artificial barriers.
> > Let's fix TLS (libssl) first, and we can tackle libcrypto in a later
> > release.
> 
> I disagree.
> 
> I think the main driver will be OpenSSL 1.1-next, which will have TLS 1.3
> support.  

For me, the main driver will be all the internal code quality
improvements in OpenSSL 1.1.0, that I hope will make the code
substantially more resilient, and subject to a lower CVE rate than
its predecessors.  Hardening of the existing TLS 1.2 implementation
will also be a win.

Sexy new features like TLS 1.3 will not be compelling for quite
some time.

I do not want to dissuade downstream distributions from adopting
OpenSSL 1.1.0 because porting is difficult to impossible.

> So the purpose of this realease will be to flush out bad code
> and bad crypto, completely refresh and overhaul many things.  And if some
> folks wait because they need to still use old, bad or unsupported, crypto
> algorithms, so be it.  Can't please everyone.  And they've got time to
> fix it before they decide they really really want TLS 1.3 :)

This may not take into account the compexity of the ecosystem, the
folks with "bad code and bad crypto" are not necessarily the
distribution maintainers who ship prebuilt packages, libraries,
and scripting languages.  Which OpenSSL should Perl's Net::SSLeay
link against?  Or some CPAN module that provides libcrypto algorithms?

The distribution maintainers face immense backwards compatibility
challenges, especially with late binding software.  We cannot be
cavalier about their problems.

> So I don't view this as an artificial barrier.  I view it as a preview
> for the real thing people will want, which is the *next* release.

I expect on the contrary, that a more solid 1.1.0 is more compelling
than a shiny 1.2.0.  Just adjusting to the API changes will be
enough work, and we want that work to start.  At least those show
up at link time.  Delaying the API adjustment by removing functionality
is likely too radical.

Yes we'd prefer to not maintain the old ciphers and digests forever,
but as soon as we're doing something other than TLS, we're supporting
data at rest not just data in motion, and data at rest has a rather
long shelf-life.

Sadly, we have to tread very carefully with algorithm removal from
libcrypto, but we have a lot more flexibility in libssl.

-- 
	Viktor.