<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 16/11/2015 16:51, Emilia Käsper
wrote:<br>
</div>
<blockquote class=" cite"
id="mid_CAGZjfUbST9_s1dJGCgWemRQbWb3ziy8kLkAmGtnNuVOZhzb9HQ_mail_gmail_com"
cite="mid:CAGZjfUbST9_s1dJGCgWemRQbWb3ziy8kLkAmGtnNuVOZhzb9HQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Thanks all for your feedback!</div>
<div><br>
</div>
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.
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>As for specific deprecation strategies:</div>
<div>- Don't forget that all applications will have to recompile
against 1.1.</div>
<div><br>
</div>
<div>- 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.</div>
<div><br>
</div>
<div>- 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.</div>
<div><br>
</div>
<div>- 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?).</div>
<div><br>
</div>
<div>- 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.</div>
</div>
</blockquote>
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.<br>
<blockquote class=" cite"
id="mid_CAGZjfUbST9_s1dJGCgWemRQbWb3ziy8kLkAmGtnNuVOZhzb9HQ_mail_gmail_com"
cite="mid:CAGZjfUbST9_s1dJGCgWemRQbWb3ziy8kLkAmGtnNuVOZhzb9HQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>- 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.</div>
<div><br>
</div>
<div>- 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.)</div>
</div>
</blockquote>
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.<br>
<blockquote class=" cite"
id="mid_CAGZjfUbST9_s1dJGCgWemRQbWb3ziy8kLkAmGtnNuVOZhzb9HQ_mail_gmail_com"
cite="mid:CAGZjfUbST9_s1dJGCgWemRQbWb3ziy8kLkAmGtnNuVOZhzb9HQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>- 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.</div>
<div><br>
</div>
<div>
<div>Here's the list of algorithms gone from BoringSSL:</div>
<div><br>
</div>
<div>IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary
curves</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>And here's the list gone from LibreSSL, from what I can
tell:</div>
<div><br>
</div>
<div>MD2, MDC2, RC5, SEED</div>
<div><br>
</div>
<div>Neither have removed CAST, and there is presumably a good
reason for that. (PGP?)</div>
<div><br>
</div>
<div>It seems to me that these can pretty safely go:</div>
<div><br>
</div>
<div>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.)</div>
</div>
</div>
</blockquote>
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).<br>
<blockquote class=" cite"
id="mid_CAGZjfUbST9_s1dJGCgWemRQbWb3ziy8kLkAmGtnNuVOZhzb9HQ_mail_gmail_com"
cite="mid:CAGZjfUbST9_s1dJGCgWemRQbWb3ziy8kLkAmGtnNuVOZhzb9HQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>MDC2</div>
<div>SEED</div>
<div>RC5 </div>
<div><br>
</div>
<div>These could probably stay (C only):</div>
<div><br>
</div>
<div>CAST</div>
<div>IDEA</div>
<div>RIPEMD (used in Bitcoin?)</div>
<div>WHIRLPOOL</div>
<div><br>
</div>
<div>as well as</div>
<div><br>
</div>
<div>BLOWFISH</div>
<div>MD4</div>
<div>RC2</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Emilia</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Nov 16, 2015 at 2:21 PM, Hubert
Kario <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:hkario@redhat.com" target="_blank">hkario@redhat.com</a>></span>
wrote:<br>
<blockquote id="Cite_8097519" class="gmail_quote cite"
style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"><span class="">On Friday 13 November
2015 14:40:33 Emilia Käsper wrote:<br>
> Hi all,<br>
><br>
> We are considering removing from OpenSSL 1.1 known
broken or outdated<br>
> cryptographic primitives. As you may know the forks
have already done<br>
> this but I'd like to seek careful feedback for
OpenSSL first to<br>
> ensure we won't be breaking any major applications.<br>
><br>
> These algorithms are currently candidates for
removal:<br>
><br>
> CAST<br>
> IDEA<br>
> MDC2<br>
> MD2 [ already disabled by default ]<br>
> RC5 [ already disabled by default ]<br>
> RIPEMD<br>
> SEED<br>
> WHIRLPOOL<br>
> ALL BINARY ELLIPTIC CURVES<br>
><br>
> My preference would be to remove these algorithms
completely (as in,<br>
> delete the code). Disabled-by-default code will
either be re-enabled<br>
> by distros (if there's widespread need for it - in
which case we<br>
> might as well leave it in) or will be poorly tested
and is likely to<br>
> just silently rot and break. This code is bloat and
maintentance<br>
> burden for us - my hope is that much of this code is
effectively dead<br>
> and can be removed.<br>
><br>
</span>> *Are you aware of any mainstream need to
continue supporting these<br>
> algorithms in OpenSSL 1.1?* Note that an older OpenSSL
library or<br>
<span class="">> binary, or a standalone implementation
or another crypto toolkit can<br>
> always be used to continue supporting a legacy
standalone<br>
> application, or to decrypt ciphertext from the
distant past. I am<br>
> looking for use cases that could cause e.g. interop
breakage between<br>
> new and old peers, or major pain to distro end-users.<br>
><br>
> These algorithms are obsolete but removing them
doesn't look feasible:<br>
><br>
> BLOWFISH - probably still in use though I don't know
where exactly?<br>
> MD4 - used in NTLM<br>
> RC2 - used in PKCS#12<br>
><br>
</span>> *Did I miss anything from the list?*<br>
<br>
I'd say that this is the wrong approach.<br>
<br>
If you have old stuff signed with MD2, and then timestamped
with MD5,<br>
SHA-1, SHA-256 over the years, with new timestamp added
every year this<br>
makes the MD2 signature _valid_ and _secure_.<br>
<br>
If you have stuff that is encrypted, but in deep storage
with any of<br>
those algorithms, then yes, it's less than optimal. Removing
support for<br>
those algorithm will make this data inaccessible. Not to
mention that<br>
stuff like IDEA or SEED may never get broken before the data
in them<br>
needs to remain secret - and after that creating a new
archive with<br>
unencrypted data after it can become public would simply
cost money.<br>
<br>
And as some pointed out, few OpenSSL users actually read
mailing lists,<br>
fewer still know what actual primitives are necessary for
their stuff to<br>
work (e.g. PKCS#8 files specify inside them the cipher and
key<br>
derivation necessary for decryption).<br>
<br>
<br>
What I think is the correct course of action, is to have in
the<br>
configuration file settings which specify the set of
algorithms that are<br>
set as available and trusted. So that we can disable them by
default and<br>
require the users to make a concious decision to enable
support for<br>
them. (Make openssl print to stderr info about them being<br>
administratively disabled when application tries using them
for bonus<br>
points).<br>
<br>
This allows to place the information about this depreciation
in a place<br>
where users will actually see it and will make them concious
of using<br>
weak and badly tested algorithms. At the same time it will
protect most<br>
of the users that don't require such obsolete algorithms.<br>
<br>
But this concious decision MUST NOT require recompilation of
the<br>
package. Few if any distributions support recompiled
packages. For many<br>
end-users this is also a hurdle they simply can't cross.<br>
<br>
And this also allows openssl to change the cryptographic
policy in<br>
stable branches without breaking the API/ABI promise.
(POODLE, FREAK,<br>
Logjam)<br>
<span class="HOEnZb"></span></blockquote>
</div>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
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 </pre>
</body>
</html>