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.
