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

[Jakob Bohm]

On 16/11/2015 16: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.
>
> 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.
>
> - 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.
There is also the point that OpenSSL is the worlds most well known 
"Swiss army knife" crypto package for non-research uses.  The more you 
overfocus on the single SSL/TLS use case, the less attractive OpenSSL 
becomes to all other uses.  If OpenSSL makes itself useless, others will 
have to reinvent it.
>
> - I believe that the OpenSSL community generally tends to overlook the 
> positive impact of change when trying to round up the negative impact 
> of breakage. Applications are generally able to move along and fix 
> things when presented with the right incentives. Applications that 
> aren't generally able to move along are rather unlikely to jump onto 
> OpenSSL 1.1, and all these algorithms will be supported as part of 
> OpenSSL 1.0.2 until 2020 for them. Finally, removing support for these 
> algorithms from OpenSSL doesn't render your encrypted storage 
> inaccessible. You can always use another implementation to 
> decrypt/re-encrypt your data, and I fully believe in the power of the 
> community in providing such tools where necessary.
>
> - 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.)
The Logjam protection was an SSL-only change.  It has NO relevance to 
the deleterious effects of crippling the non-SSL functionality in the 
OpenSSL libraries.
>
> - 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.
>
> Here's the list of algorithms gone from BoringSSL:
>
> IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves
>
> This isn't of course entirely representative of widespread usage. 
> However Google's multi-billion line codebase now builds against 
> BoringSSL and therefore largely does not depend on these algorithms. 
> Those billions of lines aren't all new and shiny code written in 2015, 
> and some of it does have to interoperate with the outside world.
>
> And here's the list gone from LibreSSL, from what I can tell:
>
> MD2, MDC2, RC5, SEED
>
> Neither have removed CAST, and there is presumably a good reason for 
> that. (PGP?)
>
> 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.)
Please read my description again.  I was arguing that the disabling of 
signature checking done in OpenSSL 1.0.0 was a mistake and is really a 
security-weakening bug.  As that bug is fixed (by reinstating, in 
general, the checking of the self-signature on root certificates), the 
problem with MD2 being disabled completely (rather than being marked as 
untrusted) will resurface, at least for data at rest (prime *example* is 
CMS signed e-mail and files signed with certificates that trace back to 
the original Verisign root).
> MDC2
> SEED
> RC5
>
> These could probably stay (C only):
>
> CAST
> IDEA
> RIPEMD (used in Bitcoin?)
> WHIRLPOOL
>
> as well as
>
> BLOWFISH
> MD4
> RC2
>
> I am on the fence about the binary curves: I am not aware of any 
> usage, really, and it's not about to pick up now.
>
> Cheers,
> Emilia
>
> On Mon, Nov 16, 2015 at 2:21 PM, Hubert Kario <hkario at redhat.com 
> <mailto:hkario at redhat.com>> wrote:
>
>     On Friday 13 November 2015 14:40:33 Emilia Käsper wrote:
>     > Hi all,
>     >
>     > We are considering removing from OpenSSL 1.1 known broken or
>     outdated
>     > cryptographic primitives. As you may know the forks have already
>     done
>     > this but I'd like to seek careful feedback for OpenSSL first to
>     > ensure we won't be breaking any major applications.
>     >
>     > These algorithms are currently candidates for removal:
>     >
>     > CAST
>     > IDEA
>     > MDC2
>     > MD2 [ already disabled by default ]
>     > RC5 [ already disabled by default ]
>     > RIPEMD
>     > SEED
>     > WHIRLPOOL
>     > ALL BINARY ELLIPTIC CURVES
>     >
>     > My preference would be to remove these algorithms completely (as in,
>     > delete the code). Disabled-by-default code will either be re-enabled
>     > by distros (if there's widespread need for it - in which case we
>     > might as well leave it in) or will be poorly tested and is likely to
>     > just silently rot and break. This code is bloat and maintentance
>     > burden for us - my hope is that much of this code is effectively
>     dead
>     > and can be removed.
>     >
>     > *Are you aware of any mainstream need to continue supporting these
>     > algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or
>     > binary, or a standalone implementation or another crypto toolkit can
>     > always be used to continue supporting a legacy standalone
>     > application, or to decrypt ciphertext from the distant past. I am
>     > looking for use cases that could cause e.g. interop breakage between
>     > new and old peers, or major pain to distro end-users.
>     >
>     > These algorithms are obsolete but removing them doesn't look
>     feasible:
>     >
>     > BLOWFISH - probably still in use though I don't know where exactly?
>     > MD4 - used in NTLM
>     > RC2 - used in PKCS#12
>     >
>     > *Did I miss anything from the list?*
>
>     I'd say that this is the wrong approach.
>
>     If you have old stuff signed with MD2, and then timestamped with MD5,
>     SHA-1, SHA-256 over the years, with new timestamp added every year
>     this
>     makes the MD2 signature _valid_ and _secure_.
>
>     If you have stuff that is encrypted, but in deep storage with any of
>     those algorithms, then yes, it's less than optimal. Removing
>     support for
>     those algorithm will make this data inaccessible. Not to mention that
>     stuff like IDEA or SEED may never get broken before the data in them
>     needs to remain secret - and after that creating a new archive with
>     unencrypted data after it can become public would simply cost money.
>
>     And as some pointed out, few OpenSSL users actually read mailing
>     lists,
>     fewer still know what actual primitives are necessary for their
>     stuff to
>     work (e.g. PKCS#8 files specify inside them the cipher and key
>     derivation necessary for decryption).
>
>
>     What I think is the correct course of action, is to have in the
>     configuration file settings which specify the set of algorithms
>     that are
>     set as available and trusted. So that we can disable them by
>     default and
>     require the users to make a concious decision to enable support for
>     them. (Make openssl print to stderr info about them being
>     administratively disabled when application tries using them for bonus
>     points).
>
>     This allows to place the information about this depreciation in a
>     place
>     where users will actually see it and will make them concious of using
>     weak and badly tested algorithms. At the same time it will protect
>     most
>     of the users that don't require such obsolete algorithms.
>
>     But this concious decision MUST NOT require recompilation of the
>     package. Few if any distributions support recompiled packages. For
>     many
>     end-users this is also a hurdle they simply can't cross.
>
>     And this also allows openssl to change the cryptographic policy in
>     stable branches without breaking the API/ABI promise. (POODLE, FREAK,
>     Logjam)
>


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151116/6b199c81/attachment-0001.html>