Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

classic Classic list List threaded Threaded
70 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

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

Emilia Käsper-2


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

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

Jeffrey Walton-3
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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Florian Weimer
In reply to this post by Viktor Dukhovni
* Viktor Dukhovni:

> If I were to guess, it would be that the base crypto implementations
> of IDEA, SEED and binary elliptic curves need to stay.  We could
> perhaps get away with removing CAST and RIPEMD.

Just one data point: CAST5 is still the default for GnuPG when using
symmetric encryption.

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

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Kurt Roeckx
On Tue, Nov 17, 2015 at 07:10:00PM +0100, Florian Weimer wrote:
> * Viktor Dukhovni:
>
> > If I were to guess, it would be that the base crypto implementations
> > of IDEA, SEED and binary elliptic curves need to stay.  We could
> > perhaps get away with removing CAST and RIPEMD.
>
> Just one data point: CAST5 is still the default for GnuPG when using
> symmetric encryption.

Not in gnupg 2 afaik.


Kurt

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

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

Benjamin Kaduk
In reply to this post by Jeffrey Walton-3
On 11/17/2015 12:00 PM, Jeffrey Walton wrote:
>
>
> Also, if OpenSSL requires iOS 9 or above, then its setting policy for users.

In some sense, yes.  But it has always done so -- OpenSSL only supports
certain platforms, and certain versions of certain platforms.  There are
prerequisites to being able to build any piece of software, and those
prerequisites can and must change as new versions of that software are
released.  In particular...

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

Will Apple still be supporting even iOS 8 in two years?  I find it hard
to make a case that OpenSSL should make an active push to support
platforms no longer receiving security updates, given that we are
supposed to be security software.  In your personal case, you seem happy
to use older versions of OS X and iOS; what is different about those
compared to OpenSSL that you could not continue using an older version
of OpenSSL if you found some functionality of the old version to be
preferable?


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

Re: Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Florian Weimer
In reply to this post by Kurt Roeckx
* Kurt Roeckx:

> On Tue, Nov 17, 2015 at 07:10:00PM +0100, Florian Weimer wrote:
>> * Viktor Dukhovni:
>>
>> > If I were to guess, it would be that the base crypto implementations
>> > of IDEA, SEED and binary elliptic curves need to stay.  We could
>> > perhaps get away with removing CAST and RIPEMD.
>>
>> Just one data point: CAST5 is still the default for GnuPG when using
>> symmetric encryption.
>
> Not in gnupg 2 afaik.

Debian stable has GnuPG 2.0.26, and it still uses CAST5:

$ gpg2 --batch --passphrase - -c < /dev/null | gpg2 --batch --passphrase - --list-packets
:symkey enc packet: version 4, cipher 3, s2k 3, hash 2
        salt 45c1df2dc3dd11c2, count 2490368 (179)
gpg: CAST5 encrypted data
:encrypted data packet:
        length: 22
gpg: encrypted with 1 passphrase
:compressed packet: algo=1
:literal data packet:
        mode b (62), created 1447798993, name="",
        raw data: 0 bytes
gpg: WARNING: message was not integrity protected

GnuPG 2.0 is still “the stable version suggested for most users”,
unfortunately.  GnuPG 2.1 has indeed switched to AES-128, but only in
September 2014.

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

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

Hubert Kario
In reply to this post by Emilia Käsper-2
On Tuesday 17 November 2015 13:21:03 Emilia Käsper 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.
That's correct. But it exists on both sides of the argument.

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

And I said that this code will certainly need to stay for 15 more, at
the very least (more on that below).

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

Now, please, tell me: how often do you go though your e-mail archive and
verify that you can decrypt and verify signatures on all the old email
you have there?

On Monday 16 November 2015 20:28:01 Richard Moore wrote:

> 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.
It's not theoretical, I know that archival systems which use CAdES,
PAdES or XAdES exist for over a decade now.

> You're making it sound like this is making the data totally
> inaccessible which is not the case.

It *is* the case.


There seems to be a lot of misunderstanding what I'm talking about so
let me start from the beginning.

As we all know, by having a RSA, DSA or ECDSA key pair (among others),
it is possible to create digital signatures of electronic documents.
Files really. It proves that a given document was created (or at least
viewed) by a user which signed the document.

But the key sizes appropriate for proving that the signature was not
constructed (counterfeited) changes in time. Same with key sizes
supported by typical PKCS#11 tokens - 10 years ago a typical USB token
wouldn't be able to create a 2048 bit RSA signature.

As we're discussing here, the hash algorithms considered as secure also
change, with some being broken as time goes one and new being created.

Finally, the key used for signing may be compromised or lost. And even
if not, it will loose validity at the "notAfter" date. The CA will loose
validity too, worse, it may stop existing completely...

This creates a problem - how do I prove that a given document was signed
while the key size was still appropriate, the hash algorithm was still
considered secure and the certificates were still valid and not-revoked?

The answer is: use a trusted third party that will sign a hash provided
by you together with a date provided by itself. It's a notary service,
proving existence of some data at some point in time. It creates a Time
Stamp.

Now on the scene enter Qualified Digital Signatures. In other words,
signatures which are considered to be equivalent to paper signatures in
_everything_ for all purposes under the law - marriage certificates,
business agreements, medical records, tax reports, etc. They require
registration (in person) with a state certified CA and use of
essentially a FIPS 140-3 Level 3 HSM for generating and storing the key.

This extends the problem of Time Stamps. Since many legal documents MUST
be kept for decades (30 years is not uncommon) we need to deal with not
only compromises of private keys, key sizes or hashes getting obsoleted
but _entire cryptosystems_ becoming obsolete.

The solution to this problem, is to regularly time stamp the document
together with all data necessary to verify original signature and all
subsequent timestamps (that means, CA certificates, intermediate CA
certificates, end-user certificates, OCSP responses, CRLs and time
stamps). This way, it is possible to digitally certify that any
cryptosystems, signatures and timestamps were created before they could
have been broken.

Now, to verify that all the data necessary for verification of previous
signatures (be it on certificates, time stamps or the original document)
is correct, the application MUST verify all those signatures (legal
requirement) *before* it adds a new timestamp.

And since those time stamps need to be created using Qualified
certificates too, usually access to those Time Stamping Authorities is
limited by TLS with user certificates, so that users need to buy every
timestamp.

So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to support
both relatively modern TLS with user certificates, preferably the newest
cryptosystems and hashes as well as the oldest ones that were
standardised and used.

That means that old algorithms MUST remain in OpenSSL as supported
functionality. It may require linking to a specific library to make the
EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
from it completely, definitely not before at least 50 years _after_ they
became obsolete and broken.
--
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

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

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

Benjamin Kaduk
On 11/18/2015 07:05 AM, Hubert Kario wrote:

> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to support
> both relatively modern TLS with user certificates, preferably the newest
> cryptosystems and hashes as well as the oldest ones that were
> standardised and used.
>
> That means that old algorithms MUST remain in OpenSSL as supported
> functionality. It may require linking to a specific library to make the
> EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
> from it completely, definitely not before at least 50 years _after_ they
> became obsolete and broken.
>

There seems to be a logical leap between these two paragraphs.  Why is
it necessary that OpenSSL be the only cryptographic library used by
CAdES-A/etc. implementations?  Is it in fact even necessary that only a
single version of a single cryptographic library be used for such
software?  While OpenSSL may try to be a general-purpose crypto library,
when a software has stringent or unusual crypto requirements, it seems
reasonable that such a software may need to involve unusual implementations.

I do not believe that OpenSSL has promised anywhere that it will support
this sort of use case.

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

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

Hubert Kario
On Wednesday 18 November 2015 11:12:59 Benjamin Kaduk wrote:

> On 11/18/2015 07:05 AM, Hubert Kario wrote:
> > So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
> > support both relatively modern TLS with user certificates,
> > preferably the newest cryptosystems and hashes as well as the
> > oldest ones that were standardised and used.
> >
> > That means that old algorithms MUST remain in OpenSSL as supported
> > functionality. It may require linking to a specific library to make
> > the EVP* with old ciphers, MACs, etc. work, but they MUST NOT be
> > removed from it completely, definitely not before at least 50 years
> > _after_ they became obsolete and broken.
>
> There seems to be a logical leap between these two paragraphs.  Why is
> it necessary that OpenSSL be the only cryptographic library used by
> CAdES-A/etc. implementations?  Is it in fact even necessary that only
> a single version of a single cryptographic library be used for such
> software?
>
> While OpenSSL may try to be a general-purpose crypto
> library, when a software has stringent or unusual crypto
> requirements, it seems reasonable that such a software may need to
> involve unusual implementations.
>
> I do not believe that OpenSSL has promised anywhere that it will
> support this sort of use case.
From the main web page of project:

  The OpenSSL Project is a collaborative effort to develop a robust,  
  commercial-grade, *full-featured*, and Open Source toolkit
  implementing the Transport Layer Security (TLS) and Secure Sockets
  Layer (SSL) protocols as well as a full-strength *general purpose*
  *cryptography library* .

(emphasis mine)

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

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

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

Blumenthal, Uri - 0553 - MITLL
In reply to this post by Benjamin Kaduk
On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
<[hidden email] on behalf of [hidden email]> wrote:

>On 11/18/2015 07:05 AM, Hubert Kario wrote:
>> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
>>support
>> both relatively modern TLS with user certificates, preferably the
>>newest
>> cryptosystems and hashes as well as the oldest ones that were
>> standardised and used.
>>
>> That means that old algorithms MUST remain in OpenSSL as supported
>> functionality. It may require linking to a specific library to make the
>> EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
>> from it completely, definitely not before at least 50 years _after_
>>they
>> became obsolete and broken.
>
>There seems to be a logical leap between these two paragraphs.  Why is
>it necessary that OpenSSL be the only cryptographic library used by
>CAdES-A/etc. implementations?
Because it used to be the only real game in town, and *people learned to
rely upon it*.

>Is it in fact even necessary that only a
>single version of a single cryptographic library be used for such
>software?

No, of course not. But after letting people depend on this “single
cryptographic library” for many years, telling them “too bad” isn’t very
nice.

>While OpenSSL may try to be a general-purpose crypto library,
>when a software has stringent or unusual crypto requirements, it seems
>reasonable that such a software may need to involve unusual
>implementations.

The requirements did not change. What changed was the maintainers
expressing their desire to stop supporting some of them.

>I do not believe that OpenSSL has promised anywhere that it will support
>this sort of use case.

Implicitly, by providing that kind of service for so long. And explicitly,
as pointed out by Hubert:

        From the main web page of project:

                The OpenSSL Project is a collaborative effort to develop a robust,
                commercial-grade, *full-featured*, and Open Source toolkit
                implementing the Transport Layer Security (TLS) and Secure Sockets
                Layer (SSL) protocols as well as a full-strength *general purpose*
                *cryptography library* .


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

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Richard Moore
In reply to this post by Hubert Kario


On 18 November 2015 at 17:57, Hubert Kario <[hidden email]> wrote:
On Wednesday 18 November 2015 11:12:59 Benjamin Kaduk wrote:
> On 11/18/2015 07:05 AM, Hubert Kario wrote:
> > So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
> > support both relatively modern TLS with user certificates,
> > preferably the newest cryptosystems and hashes as well as the
> > oldest ones that were standardised and used.
> >
> > That means that old algorithms MUST remain in OpenSSL as supported
> > functionality. It may require linking to a specific library to make
> > the EVP* with old ciphers, MACs, etc. work, but they MUST NOT be
> > removed from it completely, definitely not before at least 50 years
> > _after_ they became obsolete and broken.
>
> There seems to be a logical leap between these two paragraphs.  Why is
> it necessary that OpenSSL be the only cryptographic library used by
> CAdES-A/etc. implementations?  Is it in fact even necessary that only
> a single version of a single cryptographic library be used for such
> software?
>
> While OpenSSL may try to be a general-purpose crypto
> library, when a software has stringent or unusual crypto
> requirements, it seems reasonable that such a software may need to
> involve unusual implementations.
>
> I do not believe that OpenSSL has promised anywhere that it will
> support this sort of use case.

From the main web page of project:

  The OpenSSL Project is a collaborative effort to develop a robust,
  commercial-grade, *full-featured*, and Open Source toolkit
  implementing the Transport Layer Security (TLS) and Secure Sockets
  Layer (SSL) protocols as well as a full-strength *general purpose*
  *cryptography library* .

(emphasis mine)


​I think now is the time for those who are going to provide the 50 year support to step up to the plate then. Saying "oh but we can get it for free for the next 50 years" doesn't work.

I think your emphasis here is exactly right though, the aim is *general purpose*​ you are most definitely describing an extremely specialised purpose that has unusual requirements.

​Cheers

Rich.​


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

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

Benjamin Kaduk
In reply to this post by Blumenthal, Uri - 0553 - MITLL
On 11/18/2015 12:52 PM, Blumenthal, Uri - 0553 - MITLL wrote:

> On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
> <[hidden email] on behalf of [hidden email]> wrote:
>
>> On 11/18/2015 07:05 AM, Hubert Kario wrote:
>>> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
>>> support
>>> both relatively modern TLS with user certificates, preferably the
>>> newest
>>> cryptosystems and hashes as well as the oldest ones that were
>>> standardised and used.
>>>
>>> That means that old algorithms MUST remain in OpenSSL as supported
>>> functionality. It may require linking to a specific library to make the
>>> EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
>>> from it completely, definitely not before at least 50 years _after_
>>> they
>>> became obsolete and broken.
>> There seems to be a logical leap between these two paragraphs.  Why is
>> it necessary that OpenSSL be the only cryptographic library used by
>> CAdES-A/etc. implementations?
> Because it used to be the only real game in town, and *people learned to
> rely upon it*.
>
>> Is it in fact even necessary that only a
>> single version of a single cryptographic library be used for such
>> software?
> No, of course not. But after letting people depend on this “single
> cryptographic library” for many years, telling them “too bad” isn’t very
> nice.

I guess I'm just having a hard time wrapping my head around why, upon
hearing that the volunteer-run project is giving years' advance notice
that certain features will be removed, the response is insistence that
everything must remain supported forever, instead of using the advance
notice to investigate alternatives.  Volunteers should be allowed to
ease up when they need to, after all.


>> While OpenSSL may try to be a general-purpose crypto library,
>> when a software has stringent or unusual crypto requirements, it seems
>> reasonable that such a software may need to involve unusual
>> implementations.
> The requirements did not change. What changed was the maintainers
> expressing their desire to stop supporting some of them.

Surely the requirements for a general-purpose crypto library must change
over time!  In 1995, such a library did not (could not!) include AES
support, whereas even by 2005 it would have been pretty essential to
have.  As the state of the art advances, the library must adapt to
match, and removing components that are no longer widespread or
essential seems a natural part of that adaptation.  The requirements are
not an append-only list.

>> I do not believe that OpenSSL has promised anywhere that it will support
>> this sort of use case.
> Implicitly, by providing that kind of service for so long. And explicitly,
> as pointed out by Hubert:

Well, I see this thread as notice that the implicit support should no
longer be taken for granted, with plenty of advance notice.

> From the main web page of project:
>
> The OpenSSL Project is a collaborative effort to develop a robust,
> commercial-grade, *full-featured*, and Open Source toolkit
> implementing the Transport Layer Security (TLS) and Secure Sockets
> Layer (SSL) protocols as well as a full-strength *general purpose*
> *cryptography library* .
>
>


That text reads as if it was originally drafted 10+ years ago, when
"full-featured" meant "we support both encryption and decryption" as
well as "we provide both export-grade and strong crypto".  I'm sure we
could put some updated text in if that would help clarify what exactly
the goals of the project are.  And, as Richard notes, general-purpose
does not mean "usable for every possible specific use case under the
sun", it means "usable for most common things", which to me does not
include CAdES-A and the like.

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

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

Viktor Dukhovni
On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote:

> > No, of course not. But after letting people depend on this “single
> > cryptographic library” for many years, telling them “too bad” isn’t very
> > nice.
>
> I guess I'm just having a hard time wrapping my head around why, upon
> hearing that the volunteer-run project is giving years' advance notice
> that certain features will be removed, the response is insistence that
> everything must remain supported forever, instead of using the advance
> notice to investigate alternatives.  Volunteers should be allowed to
> ease up when they need to, after all.

Culture-clash.  Security culture says everything remotely weak must
go, but release-engineering culture emphasizes compatibilty.  The
crypto library is more of a systems component, not a security
component.  The SSL library is more of a security component than
a systems component, and has algorithm negotiation.

For example, Linux never breaks user-land, you can do all kinds of
things inside the kernel, but user-land software (for a fixed libc)
that worked before is going to continue working on new kernels.
Doing that since 1991 or so.

SunOS libc implemented multiple ABIs to ensure application
compatibility.  Many other operating systems do likewise.

For better or worse, libcrypto is part of that world.  It is a
building block library for whatever applications the users want to
use it for.  It is not a security technology in its own right.


> Surely the requirements for a general-purpose crypto library must change
> over time!  

Yes, by accretion.  And "general-purpose" does not mean "the expected
use-cases", it really means "general".

> have.  As the state of the art advances, the library must adapt to
> match, and removing components that are no longer widespread or
> essential seems a natural part of that adaptation.  The requirements are
> not an append-only list.

Except that they are, just as Linux and libc provide an append-only
set of interfaces.

> > The OpenSSL Project is a collaborative effort to develop a robust,
> > commercial-grade, *full-featured*, and Open Source toolkit
> > implementing the Transport Layer Security (TLS) and Secure Sockets
> > Layer (SSL) protocols as well as a full-strength *general purpose*
> > *cryptography library* .
>
>
> That text reads as if it was originally drafted 10+ years ago, when
> "full-featured" meant "we support both encryption and decryption" as
> well as "we provide both export-grade and strong crypto".  I'm sure we
> could put some updated text in if that would help clarify what exactly
> the goals of the project are.  And, as Richard notes, general-purpose
> does not mean "usable for every possible specific use case under the
> sun", it means "usable for most common things", which to me does not
> include CAdES-A and the like.

No, general purpose really means whatever purpose the user has in
mind.  The "most common things" is not "general purpose".

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

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

Tomas Mraz-2
On Čt, 2015-11-19 at 02:12 +0000, Viktor Dukhovni wrote:

> On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote:
>
> > > No, of course not. But after letting people depend on this “single
> > > cryptographic library” for many years, telling them “too bad” isn’t very
> > > nice.
> >
> > I guess I'm just having a hard time wrapping my head around why, upon
> > hearing that the volunteer-run project is giving years' advance notice
> > that certain features will be removed, the response is insistence that
> > everything must remain supported forever, instead of using the advance
> > notice to investigate alternatives.  Volunteers should be allowed to
> > ease up when they need to, after all.
>
> Culture-clash.  Security culture says everything remotely weak must
> go, but release-engineering culture emphasizes compatibilty.  The
> crypto library is more of a systems component, not a security
> component.  The SSL library is more of a security component than
> a systems component, and has algorithm negotiation.

What about some reasonable middle ground?
1. remove all assembler implementations of not-current crypto
2. remove all references of it from the libssl
3. remove the respective EVP_add_cipher(), EVP_add_digest(),... from the
OpenSSL_add* functions so the users have to explicitly add these to use
them automatically.
This way it is ensured that normal signature validation does not allow
for these obsolete hashes to be used, etc.
It is questionable whether it would be also good idea to disable the
active operations - i.e. encryption for legacy ciphers and signature
creation for legacy combinations of signing algorithms and hashes.

In future it might be even reasonable to move the implementations into
the libcryptolegacy.so however I am not sure this change is worth it for
1.1.0.

I believe the maintenance costs for pure C implementations in such
separate libcryptolegacy or even in the main C library would be quite
minimal. I would also expect the users of such legacy code to step up
with sharing the maintenance costs.

--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)


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

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

Hubert Kario
In reply to this post by Benjamin Kaduk
On Wednesday 18 November 2015 14:34:41 Benjamin Kaduk wrote:
> On 11/18/2015 12:52 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> > On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
> >
> > <[hidden email] on behalf of [hidden email]>
wrote:

> >> On 11/18/2015 07:05 AM, Hubert Kario wrote:
> >>> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
> >>> support
> >>> both relatively modern TLS with user certificates, preferably the
> >>> newest
> >>> cryptosystems and hashes as well as the oldest ones that were
> >>> standardised and used.
> >>>
> >>> That means that old algorithms MUST remain in OpenSSL as supported
> >>> functionality. It may require linking to a specific library to
> >>> make the EVP* with old ciphers, MACs, etc. work, but they MUST
> >>> NOT be removed from it completely, definitely not before at least
> >>> 50 years _after_ they
> >>> became obsolete and broken.
> >>
> >> There seems to be a logical leap between these two paragraphs.  Why
> >> is it necessary that OpenSSL be the only cryptographic library
> >> used by CAdES-A/etc. implementations?
> >
> > Because it used to be the only real game in town, and *people
> > learned to rely upon it*.
> >
> >> Is it in fact even necessary that only a
> >> single version of a single cryptographic library be used for such
> >> software?
> >
> > No, of course not. But after letting people depend on this “single
> > cryptographic library” for many years, telling them “too bad” isn’t
> > very nice.
>
> I guess I'm just having a hard time wrapping my head around why, upon
> hearing that the volunteer-run project is giving years' advance notice
> that certain features will be removed, the response is insistence
> that everything must remain supported forever, instead of using the
> advance notice to investigate alternatives.  Volunteers should be
> allowed to ease up when they need to, after all.
not everything

If there was a queue to axe MD5 and SHA-1 signatures, 1DES ciphers, RC4
and export grade ciphers in libssl, you can be sure you'll find me at
front of it

we already removed SSLv2 from 1.1.0 and nobody really argued that it
needs to stay

But libcrypto needs to support legacy stuff because it needs to handle
data at rest, not only data in transit. Those two are completely
different worlds.
--
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

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

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

Blumenthal, Uri - 0553 - MITLL
In reply to this post by Tomas Mraz-2
On 11/19/15, 5:01 , "openssl-dev on behalf of Tomas Mraz"
<[hidden email] on behalf of [hidden email]> wrote:

>On Čt, 2015-11-19 at 02:12 +0000, Viktor Dukhovni wrote:
>> On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote:
>>
>>> I guess I'm just having a hard time wrapping my head around why, upon
>> > hearing that the volunteer-run project is giving years' advance notice
>> > that certain features will be removed, the response is insistence that
>> > everything must remain supported forever, instead of using the advance
>> > notice to investigate alternatives.  Volunteers should be allowed to
>> > ease up when they need to, after all.
>>
>> Culture-clash.  Security culture says everything remotely weak must
>> go, but release-engineering culture emphasizes compatibilty.  The
>> crypto library is more of a systems component, not a security
>> component.  The SSL library is more of a security component than
>> a systems component, and has algorithm negotiation.
>
>What about some reasonable middle ground?
>1. remove all assembler implementations of not-current crypto
Yes, certainly. Legacy stuff is supposed to work. It may work slower.

>2. remove all references of it from the libssl

Yes, certainly. After all, this is where most of the threats and risks
live.

>3. remove the respective EVP_add_cipher(), EVP_add_digest(),... from the
>OpenSSL_add* functions so the users have to explicitly add these to use
>them automatically.

Probably yes. Cannot judge the full impact off-hand, but it makes sense.

>In future it might be even reasonable to move the implementations into
>the libcryptolegacy.so however I am not sure this change is worth it for
>1.1.0.

I doubt that such a split would make sense.

>
>I believe the maintenance costs for pure C implementations in such
>separate libcryptolegacy or even in the main C library would be quite
>minimal.

100% concur, based on my experience maintaining code (going back enough
decades to know :).

>I would also expect the users of such legacy code to step up
>with sharing the maintenance costs.

Possibly. Though, as was pointed out, it is often unclear if you are or
are not a user - can you tell for certain what crypto mechanisms (if any)
protect your archives going back to the oldest one you keep?

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

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Richard Moore


On 19 November 2015 at 15:39, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
>I believe the maintenance costs for pure C implementations in such
>separate libcryptolegacy or even in the main C library would be quite
>minimal.

100% concur, based on my experience maintaining code (going back enough
decades to know :).


​Heh. I actually tested building all releases of openssl after 0.9.7 a few months back - several refuse to build with the default options on 64 bit. In addition my experience shows that compilers get stricter over time, so old code will general need changes to work with newer compilers (even when you're only talking over a relatively short period such as 5 years). Now if this code were included in openssl but disabled by default then these problems would exist but simply be hidden until someone tried to use it. Given the user would then have to fix them (since no one else cares about their favourite dead algorithm) I don't really see what advantage having the code in the main tree offers.

Cheers

Rich.

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

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

Blumenthal, Uri - 0553 - MITLL
​Heh. I actually tested building all releases of openssl after 0.9.7 a few months back - several refuse to build with the default options on 64 bit. In addition my experience shows that compilers get stricter over time, so old code will general need changes to work with newer compilers (even when you're only talking over a relatively short period such as 5 years). Now if this code were included in openssl but disabled by default then these problems would exist but simply be hidden until someone tried to use it. Given the user would then have to fix them (since no one else cares about their favourite dead algorithm) I don't really see what advantage having the code in the main tree offers.

I did not say “no maintenance costs”. I said that I concur that the maintenance costs for such code would be minimal, which usually it is.

I’m against “disabling by default”. Removing access to such code from libssl is OK, and the correct thing to do from the security point of view. Removing from libcrypto is bad, and enough people here explained why well enough to avoid repeating the reasons.

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

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Richard Moore


On 19 November 2015 at 16:56, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
​Heh. I actually tested building all releases of openssl after 0.9.7 a few months back - several refuse to build with the default options on 64 bit. In addition my experience shows that compilers get stricter over time, so old code will general need changes to work with newer compilers (even when you're only talking over a relatively short period such as 5 years). Now if this code were included in openssl but disabled by default then these problems would exist but simply be hidden until someone tried to use it. Given the user would then have to fix them (since no one else cares about their favourite dead algorithm) I don't really see what advantage having the code in the main tree offers.

I did not say “no maintenance costs”. I said that I concur that the maintenance costs for such code would be minimal, which usually it is.

I’m against “disabling by default”. Removing access to such code from libssl is OK, and the correct thing to do from the security point of view. Removing from libcrypto is bad, and enough people here explained why well enough to avoid repeating the reasons.

​Yes, but a several people (including me) disagree with you. And one of the options that has been suggested is to keep the code but have it disabled by default.

Rich.


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

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

Blumenthal, Uri - 0553 - MITLL
I did not say “no maintenance costs”. I said that I concur that the maintenance costs for such code would be minimal, which usually it is.

I’m against “disabling by default”. Removing access to such code from libssl is OK, and the correct thing to do from the security point of view. Removing from libcrypto is bad, and enough people here explained why well enough to avoid repeating the reasons.

​Yes, but a several people (including me) disagree with you.

I know.

And one of the options that has been suggested is to keep the code but have it disabled by default.

I know. And I expressed my (negative) opinion of this option, which is better than completely wiping the code, but not by very much – as you correctly pointed out. Still, at least this way user wouldn’t have to chase down the source files of an old algorithm.

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

smime.p7s (5K) Download Attachment
1234