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 <hka...@redhat.com
<mailto:hka...@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
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
