Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Emilia Käsper-2
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?

Cheers,
Emilia



_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Jakob Bohm-7
On 13/11/2015 14:40, 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?

BlowFish is still hardcoded into some file formats that
are still in use, such as the PasswordSafe password
database format, I don't know if any related
implementations get the Blowfish code from OpenSSL
though.


IDEA was famously used in the original PGP encryption
format and as such remains useful when implementing
OpenPGP decryption on top of OpenSSL's libcrypto (as
opposed to implementing an OpenSSL emulation on top an
OpenPGP library like GNU did).  I don't know if any of
the 'OpenPGP in a high level language such as
perl/python/php' implementations use OpenSSL's IDEA
implementation as the backend though, but someone will
need to trawl through CPAN (for perl), the Linux dists
etc. to be sure.


MD2 is still present in the self-signature on some major
root certificates that are still trusted in signatures
on old/historic data and documents.  Note that the
default OpenSSL code currently skips checking the
self-signature on self-signed root certificates, but
that was done based as a workaround for the disabling
of MD2, and is based on the (unreliable) assumption
that checking their internal consistency had no value
in determining the trust.  Accepting MD2 only for this
limited role (and thus keeping the code around for that
case only) would be more secure.


The use of MD4 in NTLM is closely related to its use in
the password database format of computers that
interoperate with NTLM, SMB, CIFS, Microsoft Kerberos
extensions etc.  Those password databases and related
protocols will probably outlive NTLM itself by many
years.


WHIRLPOOL has been frequently recommended as the premier
non-NIST alternative to SHA-512, I have heard of no
reason to deprecate it.


The binary elliptic curve code in OpenSSL seems to have
a unique patent license heritage (via Sun I think) and
thus provides a unique source of such code for other
FOSS code as the Certicom and Sun patents change hands
in unpredictable ways.  I don't know if any major CA
issued ECDSA certificates using those curves, in which
case they remain important to the CMS and certificate
code in OpenSSL.  Again I have heard of no reason to
deprecate them.


I do not recall any common uses for the CAST cipher,
the MDC hash construct family or the RIPEMD hash
function family (at this time).

RC5 may be a patent problem and would probably be
disabled in most OpenSSL builds anyway.
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Benjamin Kaduk
On 11/13/2015 09:31 AM, Jakob Bohm wrote:
On 13/11/2015 14:40, 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


I wonder why single-DES is not in the above list.  (Maybe because no one has spoken up as being interested in disentangling triple-DES from single-DES?)

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.


My hope as well :)
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


As another thread calls to mind, PKCS#12 could potentially just use triple-DES.  (BTW, the CMS tests fail when openssl is configured with no-rc2, due to this; I have a WIP patch sitting around.)

MD2 is still present in the self-signature on some major
root certificates that are still trusted in signatures
on old/historic data and documents.  Note that the
default OpenSSL code currently skips checking the
self-signature on self-signed root certificates, but
that was done based as a workaround for the disabling
of MD2, and is based on the (unreliable) assumption
that checking their internal consistency had no value
in determining the trust.  Accepting MD2 only for this
limited role (and thus keeping the code around for that
case only) would be more secure.



I am not sure that I agree with the claim that this assumption is unreliable.  There have been some (heated) discussions on the IETF tls WG list recently regarding the self-signatures on trust anchors, and I have not seen any compelling arguments there for checking the self-signature.  The trust anchor is just a key and an identifier; its presence in the trust store seems necessary and sufficient to me.

The use of MD4 in NTLM is closely related to its use in
the password database format of computers that
interoperate with NTLM, SMB, CIFS, Microsoft Kerberos
extensions etc.  Those password databases and related
protocols will probably outlive NTLM itself by many
years.



The MD4 in the NTLM password hash is unsalted, for extra insecurity.  The only real reason to still be using MD4 (by way of the RC4 enctype) in Kerberos is if you need to interoperate with WinXP or Server 2003 machines, but those are not really supported anymore.  We are working to get RC4 explicitly deprecated for Kerberos at the IETF.

-Ben Kaduk

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Jakob Bohm-7
On 13/11/2015 18:00, Benjamin Kaduk wrote:
On 11/13/2015 09:31 AM, Jakob Bohm wrote:
On 13/11/2015 14:40, 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


I wonder why single-DES is not in the above list.  (Maybe because no one has spoken up as being interested in disentangling triple-DES from single-DES?)

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.


My hope as well :)
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


As another thread calls to mind, PKCS#12 could potentially just use triple-DES.  (BTW, the CMS tests fail when openssl is configured with no-rc2, due to this; I have a WIP patch sitting around.)

MD2 is still present in the self-signature on some major
root certificates that are still trusted in signatures
on old/historic data and documents.  Note that the
default OpenSSL code currently skips checking the
self-signature on self-signed root certificates, but
that was done based as a workaround for the disabling
of MD2, and is based on the (unreliable) assumption
that checking their internal consistency had no value
in determining the trust.  Accepting MD2 only for this
limited role (and thus keeping the code around for that
case only) would be more secure.



I am not sure that I agree with the claim that this assumption is unreliable.  There have been some (heated) discussions on the IETF tls WG list recently regarding the self-signatures on trust anchors, and I have not seen any compelling arguments there for checking the self-signature.  The trust anchor is just a key and an identifier; its presence in the trust store seems necessary and sufficient to me.

It is essentially a "proof-of-possession", just like the
signature on a CSR.  Another way to look at is that it is
a consistency check rather than a trust check.  One use
would be to refuse import of an invalid root CA before
even getting to the point of asking the user if she wants
to add this certificate to the trusted roots store.
Another use would be to detect accidental corruption of
the trusted roots store (e.g. from disk I/O errors or
partial disk writes during a system crash).

The use of MD4 in NTLM is closely related to its use in
the password database format of computers that
interoperate with NTLM, SMB, CIFS, Microsoft Kerberos
extensions etc.  Those password databases and related
protocols will probably outlive NTLM itself by many
years.



The MD4 in the NTLM password hash is unsalted, for extra insecurity.  The only real reason to still be using MD4 (by way of the RC4 enctype) in Kerberos is if you need to interoperate with WinXP or Server 2003 machines, but those are not really supported anymore.  We are working to get RC4 explicitly deprecated for Kerberos at the IETF.
I have not checked the details, but the fundamental issue is this:

Windows domain controller databases store only the unsalted
MD4 password hash and/or the historic LM password hash, with
most current systems configured to store only the MD4 hash.
 Thus any protocol that validates user identity via their
knowledge of their domain password would need to either
transmit the actual password to the domain controller or use
some kind of cryptographic calculation where the computer
closer to the user proves knowledge of the MD4 hash to the
domain controller server.   Historically, Microsoft has
implemented multiple such cryptographic protocols:


NTLMv1 was the oldest such protocol, based on a using DES in
a silly way vastly similar to the LM protocol.


NTLMv2 was the next version, based mostly on HMAC-MD5,
introduced in the late 1990s and still the strongest supported
when the client computer is not (yet) joined to the domain.


Microsoft-specific variants/profiles of Kerberos V are used
between modern (post 2000) domain joined computers and the
trusted domain controllers of the users login domain.  I have
not yet studied which formulas they are currently using/
recommending/planning for this case, but they will all be
constrained by the fact that the server knows nothing about
the password except its MD4 hash or some value derived
therefrom
.

Any upgrade of the password database to a new format would
either involve requesting a different form of the password
(encrypted) after a successful MD4 based login or choosing
a new form mathematically derived from the MD4 hash, such
as foo(HMAC(SHA3-512, salt, MD4(UTF16LE(password)))).  New
client protocols could challenge with salt and engage in
some zero knowledge proof of knowledge of HMAC(SHA3-512,
salt, MD4(UTF16LE(password))) .


Also note that the inherently low entropy of human-memorable
passwords means that there is little security difference
between starting from MD4(UTF16LE(password)) and starting
from SHA3-1024(UTF8(password)), what matters most is the
calculations done on top of that.

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
Reply | Threaded
Open this post in threaded view
|

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

Dr. Stephen Henson
In reply to this post by Benjamin Kaduk
On Fri, Nov 13, 2015, Benjamin Kaduk wrote:

>
> As another thread calls to mind, PKCS#12 could potentially just use
> triple-DES.  (BTW, the CMS tests fail when openssl is configured with
> no-rc2, due to this; I have a WIP patch sitting around.)
>

The issue is that some cuurent software (including major web browsers) still
produce PKCS#12 files which include 40 bit RC2 for certificate "encryption"
and OpenSSL would fail to decrypt those if it removed RC2.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Jeffrey Walton-3
In reply to this post by Emilia Käsper-2
> ALL BINARY ELLIPTIC CURVES

This one may be premature.

I understand the TLS WG is moving against it. However, I am aware of
implementations of Shoup's ECIES, and they, in turn, depend on
OpenSSL. I don't know if the ECIES implementations rely solely on
prime fields or not, however.

> BLOWFISH - probably still in use though I don't know where exactly?

Linux password files and associated tools, like John the Ripper (JtR).

OpenSSL is a good toolkit for research purposes. But if research is
not a goal, then that's understandable. There are other crypto
libraries that include research as a goal.

Jeff

On Fri, Nov 13, 2015 at 8:40 AM, Emilia Käsper <[hidden email]> 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?
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Hooman Fazaeli
In reply to this post by Emilia Käsper-2
On 11/13/2015 5:10 PM, 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?

Cheers,
Emilia




_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Regarding that hardware acceleration and aes-ni is not yet common among
today desktops
and mobile devices, rc5 is a very good choice in situations
where you need a reasonably secure and yet fast cipher (as 'openssl speed' shows,
rc5 is 2.5 times faster than aes-128 w/o aes-ni. We develop a tunneling app that uses
rc5 for LAN to gateway encryption).

So, pls. do no remove rc5.


-- 
Best regards
Hooman Fazaeli

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Emilia Käsper-2
In reply to this post by Emilia Käsper-2
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.

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

- 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.)
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 <[hidden email]> 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)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic


_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: [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.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Jakob Bohm-7
In reply to this post by Emilia Käsper-2
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Emilia Käsper-2
In reply to this post by Emilia Käsper-2
One more time,

I know that someone, somewhere is probably using any given feature of OpenSSL. I am looking to gather information about concrete, actively maintained applications that may be using one of those algorithms, to build a more complete picture.

If you are aware of a concrete use of MD2 or any of the other algorithms, please let us know!

Thanks,
Emilia

On Mon, Nov 16, 2015 at 7:25 PM, Hubert Kario <[hidden email]> wrote:
On Monday 16 November 2015 16:51:10 Emilia Käsper wrote:
> 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.) 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.

I'm afraid you're too focused on TLS/SSL use case. And while it is
important it's not the only use case the OpenSSL does serve.

And for what it's worth, I'm very much *for* removing as much (and as
fast as possible) support for the old junk (or unused stuff - like
curves < 256 bit) in TLS. Search the archives for "Insecure DEFAULT
cipher set" for an example.

But stuff like this:

> The argument that someone somewhere may want to keep verifying
> old MD2 signatures on self-signed certs

is not true. I was talking about document signatures, time stamps, CRL
signatures and certificate signatures in general. Not the trust anchors
or their self-signatures.

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic


_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Richard Moore

On 16 November 2015 at 19:05, Hubert Kario <[hidden email]> wrote:
Example: CAdES V1.2.2 was published in late 2000, the first serious
attacks on MD2 were not published until 2004. I think it is not
unreasonable for CAdES-A documents to exist today which were originally
signed with MD2 while it was still considered secure and that are still
relevant today, just 15 years later.


​This doesn't explain why the code needs to exist in future versions of openssl. The previous ones aren't going to vanish and can be compiled and used to rescue data in theoretical edge cases like this. You're making it sound like this is making the data totally inaccessible which is not the case.

Cheers

Rich.​
 

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Matt Caswell-2
In reply to this post by Emilia Käsper-2


On 16/11/15 15: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.

We can significantly reduce that liability by removing any assembler
optimisations. Also just because something is available doesn't mean it
has to be "default". We can have good defaults whilst keeping old crypto.


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

Disabling algorithms isn't the right answer IMO. I do like the idea of a
"liblegacycrypto". That way people that only have need of current
up-to-date crypto can stick with the main library. Others who need the
older crypto can still get at it. Yes, that means we still have to
maintain this code - but I don't see it as that big a burden.

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

Being the "swiss army knife" is no bad thing (even where that includes
old crypto). We just have to find a way to separate the two concerns:
current crypto (and only current crypto) for most (and probably most
importantly for libssl users); broader crypto support for those that
want it (which is why I like the liblegacycrypto idea because it enables
us to do that).


> 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.)
> MDC2
> SEED
> RC5

All candidates for liblegacycrypto IMO rather than deletion.

Whether this is the right thing to do in the 1.1.0 timeframe is another
consideration though. Viktor's arguments are quite convincing.

Matt
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Salz, Rich
In reply to this post by Emilia Käsper-2

 

Ø  If you are aware of a concrete use of MD2 or any of the other algorithms, please let us know!

 

Also, note that we have an extended alpha and-beta test period, so we can add things back if mistakes are made.

 

                /r$

 


_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Walton-3
In reply to this post by Emilia Käsper-2
> 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.)
> ...
Apple still provides two Verisign certificates using
md2WithRSAEncryption. Confer,
https://support.apple.com/en-us/HT203065.

Jeff
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Walton-3
In reply to this post by Matt Caswell-2
>> 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.
>
> We can significantly reduce that liability by removing any assembler
> optimisations. Also just because something is available doesn't mean it
> has to be "default". We can have good defaults whilst keeping old crypto.

Zooko Wilcox O'Hearn recently gave a talk at a software assurance
conference on the downsides of assembly language routines in software.
I'm trying to locate it now. All in all, this is probably a move in
the right direction, especially for non-contemporary algorithms, to
help sunset them and maintain them with minimal effort.

Its probably a good idea for mainstream algorithms, too. But the guys
I know who provide the highest-performance implementations probably
won't want to leave it to a compiler.

Jeff
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Emilia Käsper-2
In reply to this post by Jeffrey Walton-3


On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton <[hidden email]> wrote:
> 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.)
> ...
Apple still provides two Verisign certificates using
md2WithRSAEncryption. Confer,
https://support.apple.com/en-us/HT203065.

Setting aside the debate of whether verifying trust store signatures is useful, whether verifying MD2 signatures has any practical security value, or whether OpenSSL + iOS is a meaningful combination:

This is iOS7. The current release is iOS9 (trust store here: https://support.apple.com/en-us/HT205205, MD2 certs are gone).

Arguments like this illustrate a fundamental misunderstanding in this thread. We are not pulling the carpet from any users TODAY. We are asking whether there are applications that will need this code 2..3..5 years down the line. When I referred to the fact that users of 1.1 will have to recompile, I didn't mean that errors would be revealed by recompilation. I meant that you would have to be an actively maintained application or library, and be doing a new release, and be stuck using an old algorithm, to even be impacted by this change.




Jeff
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Mark H. Wood
In reply to this post by Matt Caswell-2
With regard to the idea that one can simply make older algorithms
Somebody Else's Problem:  is it *known* that another viable,
well-maintained product sees this as one of its roles?  That would be
more reassuring, I think, than just hoping that some unknown group
will step into the gap.

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Walton-3
In reply to this post by Jeffrey Walton-3
>> We can significantly reduce that liability by removing any assembler
>> optimisations. Also just because something is available doesn't mean it
>> has to be "default". We can have good defaults whilst keeping old crypto.
>
> Zooko Wilcox O'Hearn recently gave a talk at a software assurance
> conference on the downsides of assembly language routines in software.
> I'm trying to locate it now. All in all, this is probably a move in
> the right direction, especially for non-contemporary algorithms, to
> help sunset them and maintain them with minimal effort.

My bad... I just talked to Zooko about the presentation. He was not
able to attend the conference, so there is no presentation to link to.

However, here is the write-up in the Tahoe-LAFS Bug Reporter:
https://tahoe-lafs.org/trac/pycryptopp/ticket/85#comment:20. It makes
the case for No-ASM. (And was the corpus of knowledge for the
presentation).

Jeff
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Walton-3
In reply to this post by Emilia Käsper-2
On Tue, Nov 17, 2015 at 7:21 AM, Emilia Käsper <[hidden email]> wrote:

>
>
> On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton <[hidden email]> wrote:
>>
>> > 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.)
>> > ...
>> Apple still provides two Verisign certificates using
>> md2WithRSAEncryption. Confer,
>> https://support.apple.com/en-us/HT203065.
>
>
> Setting aside the debate of whether verifying trust store signatures is
> useful, whether verifying MD2 signatures has any practical security value,
> or whether OpenSSL + iOS is a meaningful combination:
>
> This is iOS7. The current release is iOS9 (trust store here:
> https://support.apple.com/en-us/HT205205, MD2 certs are gone).
>
> Arguments like this illustrate a fundamental misunderstanding in this
> thread. We are not pulling the carpet from any users TODAY. We are asking
> whether there are applications that will need this code 2..3..5 years down
> the line.

My bad... I was not arguing either way. I was just presenting facts.

Also, if OpenSSL requires iOS 9 or above, then its setting policy for users.

I still have iOS 6, 7 and 8 devices because (1) some of my hardware is
old and abandoned by Apple (they are trying to set policy, too, in an
effort to boost sales). (2) I dislike the "cartoony" interface of iOS
7 and above. (3) I have down level OS X operating systems (due to
operational requirements and personal taste), and they can't talk to
iOS 8 or 9 devices.

Jeff
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
12