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

[Viktor Dukhovni]

On Mon, Nov 16, 2015 at 04:51:10PM +0100, Emilia Käsper wrote:

> As for specific deprecation strategies:
> - Don't forget that all applications will have to recompile against 1.1.

The EVP_get_cipherbyname() and EVP_get_digestbyname() interfaces
remain, so nothing changes at compile-time.  Most code does not
use EVP_<algorithm-name>() directly.  This means that:

    * Most errors are not caught at compile time.

    * Porting is not the difficult part, the much more difficult
      problem is dealing with runtime access to any algorithms needed
      to handle data at rest.

> - 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.

Removing assembly support would substantially lower support cost.
For many of the algorithms we can likely find a reference implementation
in an RFC or similar standards document, if our own code is
substantially more refined (and requires greater support effort).

> - 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.

These don't help with EVP "by name" indirection.

> - 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?).

Yes, and probably.

> - 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.

Researchers can indeed use older toolkits, my concern is real users,
with non-SSL applications (data at rest).

> - Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty
> widespread MySQL breakage. That made MySQL backport a change increasing the
> DH key length from 512 to 2048 bits. For end user security, it's a win. I
> would prefer that we start cashing in these improvements before the next
> Logjam happens. (This is my view; as you can see views differ even within
> the team.)

This is SSL/TLS where we have algorithm agility.  I support the
Logjam changes.  It is likely time for us to take the next (not
final) step from 768 to 1024 as the min prime size.

> - On binary elliptic curves: with recent cryptographic advances, I believe
> these are now firmly planted in the "internet archive" category, even if
> not practically broken yet. The other reason for removing these is that our
> implementations are crappy. They're not constant-time, and they've been
> shown to contain bugs. Improving upon these implementations is not a good
> use of dev time imo, given their decreasing credibility.

I agree they need to go from SSL/TLS.  What about S/MIME and CMS?

> Here's the list of algorithms gone from BoringSSL:
> 
> IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves

Boring SSL has a very narrow user base.  By all means drop
as much as you can get away with.

> And here's the list gone from LibreSSL, from what I can tell:
> 
> MD2, MDC2, RC5, SEED

Likewise, not a wide user base.  We can make incremental steps,
drop assembly support and SSL/TLS codepoints in this release, and
assess things from there.  My hope is that the support cost of a
stable reference implementation in C (yes, likely not constant
time) is not that onerous.

-- 
	Viktor.