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

Thu Feb 11 19:43:22 UTC 2016

Sorry to revive this old thread, I did not see any recent updates.
If there are - please point me that way, and apologies in advance.

I saw a reference to SunOS libc compatibility issues, implying we
never remove functionality. I want to be clear - we do.  We do it
by giving our customers advanced notice, and typically only do
so in a "minor" release (using SunOS version numbering, 5.9, 5.10
and 5.11 were "minor" releases. 5.10.1 (or S10U1) was an update/patch
release).

We give the customers advance notice, and typically continue
to support the feature on the currently released OS and it's updates,
and remove it from the next minor.  For example, all S10 updates
may still support the feature, and it disappeared in S11.

As others have noted, it is impossible to maintain all code forever.
It will create bugs.

I removed the "crypt(1)" command from Solaris 11, and "vi -x / -C" options
as well, because they were based on the ENIGMA rotor. VERY insecure.

We gave notice, told customers they should switch to our
new encrypt(1) command (which had AES available) and made the move.

I like Todd's suggestion (someone else made a similar one, too), but
would take it a step further and prehaps only allow decryption/
verification with these old algorithms when enabled. (if possible)

You can see some crypto related EOF announcements for Solaris here:
http://www.oracle.com/technetwork/systems/end-of-notices/eonsolaris11-392732.html

Thanks

Valerie

On 11/20/15 02:26 PM, 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.
>
> --
> -Todd Short
> // tshort at akamai.com <mailto:tshort at akamai.com>
> // "One if by land, two if by sea, three if by the Internet."
>
> --
> -Todd Short
> // tshort at akamai.com <mailto:tshort at akamai.com>
> // "One if by land, two if by sea, three if by the Internet."
>
>> On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu
>> <mailto:uri at ll.mit.edu>> wrote:
>>
>> On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
>> <openssl-dev-bounces at openssl.org <mailto:openssl-dev-bounces at openssl.org> on behalf of
>> bkaduk at akamai.com <mailto:bkaduk at akamai.com>> 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
>
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

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