[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"
<openssl-dev-bounces at openssl.org on behalf of matt at openssl.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4308 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151116/8d6cf21e/attachment.bin>