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

[Valerie Anne Fenwick]

Hi Jakob -

On 11/22/15 08:17 PM, Jakob Bohm wrote:
> On 20/11/2015 23:26, Short, Todd wrote:
>> While I am all for simplicity, I also think that removing functionality is a “bad idea”.
>>
>> To reduce the support burden, deprecate the ciphers:
>> 1. Under support, indicate that these ciphers will no longer receive fixes.
>> 2. Remove any assembly implementations
>> 3. Disable them by default.
>>
>> I suggest following the 80/20 rule (sometimes the 95/5 rule):
>>
>> Those “who care” (the minority) about the ciphers can re-enable them and rebuild the
>> library.
>> Those “who don’t care” (the majority) about the ciphers, should get the functionality
>> that most people care about, basically SSL/TLS connectivity.
>>
> You all seem to misunderstand the fundamental release engineering
> issues involved.
>
> 1. Very shortly after you release OpenSSL 1.1.0, many
>    distributions and pointy haired managers will blindly
>    switch to the new version as the only version available.
>     This will not at all await the "end of support" for
>    OpenSSL 1.0.x .  So breaking changes will cause harm much
>    sooner than you claim.

As one of those pointy haired managers, I have to say that
this scenario is simply not possible with the ABI incompatibility
between OpenSSL 1.0.2 and OpenSSL 1.1.0 - applications will
have to be updated, too. (unless I'm completely misunderstanding
something). So, most likely we're looking at a universe where
both will coexist for awhile (that seems to match up with
OpenSSL's support plans as well).

Think of this like when OpenSSL went from 0.9.8 to 1.0.0.
Both co-existed for quite awhile.

>
> 2. Because of the need to easily keep up with routine security
>    updates to OpenSSL, it is highly impractical to maintain
>    locally reconfigured build scripts and patches, though some
>    of us have no choice (and are still struggling with the
>    massively huge and disorganized code reformatting in the
>    middle of the 1.0.1 security update series).

I do not envy this work, but we're talking about a security
toolkit - it should not stay in the past. It's, quite simply,
dangerous to do so.

>
> 3. When distributions upgrade OpenSSL, many applications that
>    have not been actively and deliberately ported to the new
>    OpenSSL version will be blindly recompiled with the new
>    versions, and if they break, random developers with no
>    understanding of either the application, OpenSSL or even
>    security will do ill-informed rushed patches to try to undo
>    the breakage you caused.

Sadly, that happens when any toolkit updates.

>
> 4. OpenSSL is THE primary crypto library for the FOSS universe.
>    You may be volunteers, but you are working on a massively
>    important piece of software, not some random optional library.

Yes, but they are still allowed to change for the better.

GnuTLS did this as well, between their 2.x release and 3.x.
There is precendence. It is not pain free, but it is what
we all need to do to make a better and safter internet.

Bad choices made now will haunt us for another 10+ years.

Valerie

>
> 5. In these times of panic and marshal law, it is essential
>    that the key resources for open source crypto remain
>    unrestrained by the politics of any single country, such that
>    the sudden outlawing of crypto in the current home of the
>    maintainers does not prevent the project from being continued
>    by a different team in a different country.  This makes it
>    essential not to tie any legal or technical aspect to a single
>    place, country, political alliance, company or person.  It is
>    also critical to avoid any and all legal ties to the
>    historically most problematic jurisdictions, such as the US.
>     So don't pay people through any US bank accounts, foundations
>    or legal entities.  Don't keep any technical assets (such as
>    repositories or mail archives) in one country.  Don't create
>    legal documents that tie any license permissions to any
>    specific country or organization.
>     These same considerations exclude any of the US based
>    libraries and forks from being relevant outside that country.
>
> 6. All of this requires a lot more caution and a lot less
>    arrogance from the people making decisions about changes
>    in the OpenSSL library and project.
>
>
> Enjoy
>
> Jakob


Valerie
-- 
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic & Key Management Technologies, Manager
Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.