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

[Emilia Käsper]

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

Re: [openssl-dev] [openssl-users] 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_() 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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] certificate signing using rsa pss algorithm?

[weber]

Thanks for your reply.

Am 12.11.2015 um 18:45 schrieb stefan.n...@t-online.de:

 Hi,

You might want to upgrade to OpenSSL-1.0.2 which seems to support the
  RSA PSS algorithm, see https://openssl.org/news/changelog.html#x5.

  Regards,
   Stefan

...

we are up to the most current version, i.e. Snippet OpenSSL 1.0.2d 9 Jul 
2015.


Trying the commandline tool
openssl req -new -x509 -nodes -sha256 -days 365 -newkey rsa:2048 -out 
rca.pubcert.pem -keyout rca.privkey.pem -pkeyopt rsa_padding_mode:pss 
-pkeyopt rsa_pss_saltlen:-2 -passin pass:

... leads to ...

Loading 'screen' into random state - done
parameter error "rsa_padding_mode:pss"
10584:error:0408F090:rsa routines:PKEY_RSA_CTRL:illegal or unsupported 
padding mode:.\crypto\rsa\rsa_pmeth.c:517:
10584:error:06089093:digital envelope 
routines:EVP_PKEY_CTX_ctrl:command not 
supported:.\crypto\evp\pmeth_lib.c:405:

...

Since we found explicit exclusion of PSS padding for cert signing in 
.\crypto\rsa\rsa_pmeth.c:501, we guess PSS signing of certificates is 
currently not officially supported.


So we've just asked for the reason why, since we're looking for 
certificates which may satisfy security needs for decades.


Regards
--
Christian Weber
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4141] GOST ciphersuites

[Stephen Henson via RT]

On Sun Nov 15 10:04:28 2015, beld...@gmail.com wrote:
> Hello!
>
> In the commit 5e3d21fef150f020e2d33439401da8f7e311aa24 you set
> the SSL_SSLV3 for the GOST ciphersuites. But the GOST ciphersuites are not
> usable with SSLv3, they require TLSv1.
>
> Could you turn the flag back for the GOST ciphersuites?
>

Does that commit break anything? It should not change the previous
functionality in any way because we also had this in ssl_locl.h:

# define SSL_TLSV1 SSL_SSLV3/* for now */

The subsequent commits change SSL_TLSV1 so it really disables ciphersuites in
SSL v3 (before it didn't) and adds the flag to PSK+SHA2 ciphersuites, We can
add SSL_TLSV1 to the GOST ciphersuites but that will change the behaviour from
what it was before.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario]

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

signature.asc
Description: This is a digitally signed message part.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Emilia Käsper]

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  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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario]

On Monday 16 November 2015 19:51:08 Emilia Käsper wrote:
> 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!

And I'm saying that it is next-to impossible for me to say for certain 
because standards like CMS, S/MIME, PKCS#8 and X.509 are extensible and 
self descriptive. The file itself says which algorithms are needed to 
process it.

So without access to _all_ _data_ that the applications need to process 
it is impossible for me to tell which of those algorithms are necessary 
for continued operation of those applications.


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.

> Thanks,
> Emilia
> 
> On Mon, Nov 16, 2015 at 7:25 PM, Hubert Kario  
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

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

signature.asc
Description: This is a digitally signed message part.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario]

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

signature.asc
Description: This is a digitally signed message part.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Peter Waltenberg]

The reason for keeping the old crypto. algorithms around is the obvious
one, that's been stated over and over. OpenSSL's SSL isn't the only
consumer of the algorithms, remove the low level algorithms and you risk
breaking more than OpenSSL.  SSH, IKE,IPSec, Kerberos and I'm sure there
are more, and the scripting languages like Perl that use OpenSSL to provide
algorithm support.

There are a lot of ecosystems built on top of OpenSSL's crypto, it's not
just SSL, and for someone like a distro. maintainer it's between a rock and
a hard place, stick with the old code and patch the security
vulnerabilities, or break stuff. Which is why them being still available in
the old code isn't a good enough answer to the problems this would create.

And in this case 'breaking stuff' is unecessary. Do what you like with TLS
in terms of pruning algorithms in use, but removing the algorithms is a lot
like burning books in a library for being irrelevant. They may be
irrelevant to you, but they aren't necessarilly irrelevant to everyone.

Peter





From:   Richard Moore 
To: openssl-dev@openssl.org
Cc: openssl-us...@openssl.org
Date:   17/11/2015 06:29
Subject:Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 -
seeking feedback
Sent by:"openssl-dev" 




On 16 November 2015 at 19:05, Hubert Kario  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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Moore]

On 16 November 2015 at 19:05, Hubert Kario  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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4141] GOST ciphersuites

[Dmitry Belyavsky via RT]

Dear Stephen,

On Mon, Nov 16, 2015 at 5:22 PM, Stephen Henson via RT 
wrote:

> On Sun Nov 15 10:04:28 2015, beld...@gmail.com wrote:
> > Hello!
> >
> > In the commit 5e3d21fef150f020e2d33439401da8f7e311aa24 you set
> > the SSL_SSLV3 for the GOST ciphersuites. But the GOST ciphersuites are
> not
> > usable with SSLv3, they require TLSv1.
> >
> > Could you turn the flag back for the GOST ciphersuites?
> >
>
> Does that commit break anything? It should not change the previous
> functionality in any way because we also had this in ssl_locl.h:
>

No, it does not break our tests.


>
> # define SSL_TLSV1 SSL_SSLV3/* for now */
>
> The subsequent commits change SSL_TLSV1 so it really disables ciphersuites
> in
> SSL v3 (before it didn't) and adds the flag to PSK+SHA2 ciphersuites, We
> can
> add SSL_TLSV1 to the GOST ciphersuites but that will change the behaviour
> from
> what it was before.
>

Usage of the GOST ciphersuites with the SSLv3 protocol is not specified, so
the change should not affect the GOST-related behaviour.
So I think it will be better for clarity.

Thank you!

-- 
SY, Dmitry Belyavsky

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

> On 16 November 2015 at 19:05, Hubert Kario  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.

Of course people can keep the current OpenSSL version indefinitely – and if
the maintainers are too aggressive, it might just happen.

But the vast majority of the uses would like to upgrade to new releases with
hopefully more bugs fixed and fewer bugs introduced – and maintain their
current functionality. Because if the new version stops decrypting their
documents, who needs it?

Several people pointed out: SSL/TLS is where the algorithm agility is, where
the exploits are, and what needs to be pruned. So remove the dead wood from
libssl. Leave libcrypto alone – it is useful as-is, and real-life big
packages (like Perl) depend on it providing all the services it currently
offers. Don’t punish users for choosing OpenSSL library to handle their
non-SSL cryptographic needs and implicitly trusting the developers that they
won’t be left in the cold.




smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4141] GOST ciphersuites

[Dmitry Belyavsky]

Dear Stephen,

On Mon, Nov 16, 2015 at 5:22 PM, Stephen Henson via RT 
wrote:

> On Sun Nov 15 10:04:28 2015, beld...@gmail.com wrote:
> > Hello!
> >
> > In the commit 5e3d21fef150f020e2d33439401da8f7e311aa24 you set
> > the SSL_SSLV3 for the GOST ciphersuites. But the GOST ciphersuites are
> not
> > usable with SSLv3, they require TLSv1.
> >
> > Could you turn the flag back for the GOST ciphersuites?
> >
>
> Does that commit break anything? It should not change the previous
> functionality in any way because we also had this in ssl_locl.h:
>

No, it does not break our tests.


>
> # define SSL_TLSV1 SSL_SSLV3/* for now */
>
> The subsequent commits change SSL_TLSV1 so it really disables ciphersuites
> in
> SSL v3 (before it didn't) and adds the flag to PSK+SHA2 ciphersuites, We
> can
> add SSL_TLSV1 to the GOST ciphersuites but that will change the behaviour
> from
> what it was before.
>

Usage of the GOST ciphersuites with the SSLv3 protocol is not specified, so
the change should not affect the GOST-related behaviour.
So I think it will be better for clarity.

Thank you!

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Sands, Daniel]

On Tue, 2015-11-17 at 00:01 +, Viktor Dukhovni wrote:

On Mon, Nov 16, 2015 at 11:23:52PM +, Matt Caswell wrote:



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.



What becomes a bit tricky is having an EVP interface that can find
the algorithms in liblegacrypto.  This I think means two different
builds of the crypto library, one that depends on liblegacycrypto
and provides its algorithms, and another than does not.


Is this beyond the necessity to register EVP algorithms?  If not, a simple 
function call to register the legacy crypto functions, which would be contained 
in the legacy library, should be enough.


Some applications might be linked directly to "-secure" or "-compat"
to make sure they get one or the other.  This is a bunch of work.


If you're going to re-link at all, then the above suggestion seems like less 
cost.  For the legacy library, it would simply be maintained as if it were a 
3rd party add-on.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

Huge +1.

I find Viktor’s arguments more than convincing - irrefutable.

As for “weakening the library”, I don’t find this argument correct. It is
not about libssl - it’s about libcrypto. Quite a different animal.
-- 
Regards,
Uri Blumenthal





On 11/16/15, 18:23 , "openssl-dev on behalf of Matt Caswell"
 wrote:

>
>Meant to send this to openssl-dev not openssl-users so resending...
>
>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-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Viktor Dukhovni]

On Mon, Nov 16, 2015 at 11:23:52PM +, Matt Caswell wrote:

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

What becomes a bit tricky is having an EVP interface that can find
the algorithms in liblegacrypto.  This I think means two different
builds of the crypto library, one that depends on liblegacycrypto
and provides its algorithms, and another than does not.

Systems might then ship with:

libcrypto-legacy.so - Just the legacy algorithms

libcrypto-compat.so - Libcrypto that supports the above
libcrypto-secure.so - Libcrypto with just the strong algos

libcrypto.so- Symlink to one of the two above

Some applications might be linked directly to "-secure" or "-compat"
to make sure they get one or the other.  This is a bunch of work.

At this time, with the resources at our disposal, I think it makes
more sense to take a more gradual approach and just drop the assembly
support.


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

I like the idea, but don't see a manageable implementation...

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

The timeline is a concern.  We're fairly far into the 1.1.0
development cycle (alphas and betas soon), and this is a major
change.  I think major changes like removing the ciphers or a whole
new optional library should wait for a better opportunity.

-- 
Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Salz, Rich]

> Don’t punish users for choosing OpenSSL library to handle their non-SSL 
> cryptographic needs and implicitly trusting the developers that they won’t be 
> left in the cold.

Can we please be less inflammatory?

Old unused code is a security risk.  We’re trying to reduce the attack surface 
*responsibly.*

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Matt Caswell]

Meant to send this to openssl-dev not openssl-users so resending...

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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Peter Waltenberg]

Why not offer another set of  get_XYZ_byname() which resticts the caller to
socially acceptable algorithms. Or allows the opposite, it really doesn't
matter but restricted being the newer API breaks less code by default.

Give it the same call syntax and it's simply an #ifdef in the OpenSSL
headers for anyone who wants to spend hours working out why their code
doesn't work any more.

i.e. EVP_get_digestbyname() becomes EVP_get_digestbyname_r(), and if anyone
actually wants only the restricted set from say a Linux distro. they can
#define  EVP_get_digestbyname(a) EVP_get_digestbyname_r(a)

At the crypto library level this is just maths and it really doesn't make
any sense to try and enforce policy at this point. I can understand the
maintenance issues, but C code really isn't a problem and dropping
algorithms from the sources here simply makes more work for other people
elsewhere.

Peter




From:   Viktor Dukhovni 
To: openssl-dev@openssl.org
Date:   17/11/2015 10:02
Subject:Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete
crypto from OpenSSL 1.1 - seeking feedback
Sent by:"openssl-dev" 



On Mon, Nov 16, 2015 at 11:23:52PM +, Matt Caswell wrote:

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

What becomes a bit tricky is having an EVP interface that can find
the algorithms in liblegacrypto.  This I think means two different
builds of the crypto library, one that depends on liblegacycrypto
and provides its algorithms, and another than does not.

Systems might then ship with:

 libcrypto-legacy.so - Just the legacy algorithms

 libcrypto-compat.so - Libcrypto that supports the
above
 libcrypto-secure.so - Libcrypto with just the 
strong
algos

 libcrypto.so- Symlink to one of the
two above

Some applications might be linked directly to "-secure" or "-compat"
to make sure they get one or the other.  This is a bunch of work.

At this time, with the resources at our disposal, I think it makes
more sense to take a more gradual approach and just drop the assembly
support.


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

I like the idea, but don't see a manageable implementation...

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

The timeline is a concern.  We're fairly far into the 1.1.0
development cycle (alphas and betas soon), and this is a major
change.  I think major changes like removing the ciphers or a whole
new optional library should wait for a better opportunity.

--
 Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Salz, Rich]

Ø  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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev