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

2015-11-17 Thread Matt Caswell 


On 17/11/15 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 just limited to
OpenSSL_add_all_algorithms()/OpenSSL_add_all_ciphers()/OpenSSL_add_all_digests()?

How about if those were macros that just picked up the relevant
implementation based on a define. So in evp.h, something like:

#ifdef OPENSSL_LEGACY_ALGS
void OpenSSL_add_all_legacy_algorithms();
void OpenSSL_add_all_legacy_ciphers();
void OpenSSL_add_all_legacy_digests();
#define OpenSSL_add_all_algorithms() OpenSSL_add_all_legacy_algorithms()
#define OpenSSL_add_all_ciphers() OpenSSL_add_all_legacy_ciphers()
#define OpenSSL_add_all_digests() OpenSSL_add_all_legacy_digests()
#else
void OpenSSL_add_all_main_algorithms();
void OpenSSL_add_all_main_ciphers();
void OpenSSL_add_all_main_digests();
#define OpenSSL_add_all_algorithms() OpenSSL_add_all_main_algorithms()
#define OpenSSL_add_all_ciphers() OpenSSL_add_all_main_ciphers()
#define OpenSSL_add_all_digests() OpenSSL_add_all_main_digests()
#endif

OpenSSL_add_all_legacy_ciphers() would call
OpenSSL_add_all_main_ciphers() and add all the legacy ones in too.
Similarly for the other functions.

Then you just compile apps which don't need legacy support with
"-lcrypto", and apps that do with "-DOPENSSL_LEGACY_ALGS -lcrypto
-lcrypto-legacy"


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

I don't think you would need libcrypto-compat if you took the approach
above.

I'm wondering whether splitting libcrypto into 3 might be worthwhile:

libcrypto-core.so   - Core elements of libcrypto needed by libssl
libcrypto.so- Would depend on libcrypto-core. Adds mainstream and
current crypto stuff that isn't needed by libssl
libcrypto-legacy.so - Would depend on libcrypto and libcrypto-core. Just
the legacy algorithms.

That way users who only have an interest in libssl don't have to carry
around all the other stuff that libcrypto provides - only those bits
they need. Apps using libcrypto directly can mostly just forget about
libcrypto-legacy and just add it if they really need it.

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

2015-11-17 Thread Jeffrey Walton 
On Mon, Nov 16, 2015 at 9:06 PM, Peter Waltenberg 
wrote:

> 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.
>
This is an interesting idea. For completeness, it has failed in other
contexts. For example, the IETF's TLS Working Group refuses to provide such
an abstraction. See, for example,
https://www.ietf.org/mail-archive/web/tls/current/msg17611.html.
___
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

2015-11-17 Thread Peter Waltenberg 

> This is an interesting idea. For completeness, it has failed in other
contexts

Well yes but it's a different context. Policy level rather than capability,
That's why I'm not in favour of removing algorithms, even changing policy
higher up the stack can cause problems, but removing basic capabilities
tends to have even unwanted side effects. I obviously have a personal
interest in this, in my case it's because I work for a company that does
provide insane support lifetimes for products.

For libcrypto itself the attack surface is near zero, it doesn't open
sockets, connect to networks, accept input. It's simply a toolbox and
there's always something else between libcrypto and an attack, if SSL
doesn't want to use MD5, well don't use MD5 but there are other users of
the toolbox. As an analogy throwing out all those 3/8th spanners just
because you've officially gone metric doesn't always work that well in
practice either.

Peter








 Phone: 61-7-5552-4016 L11 & L7 
Seabank 
 E-mail: pwal...@au1.ibm.comSouthport, QLD 
4215 
  
Australia 








From:   Jeffrey Walton <noloa...@gmail.com>
To: OpenSSL Developer ML <openssl-dev@openssl.org>
Date:   17/11/2015 20:23
Subject:        Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete
    crypto from OpenSSL 1.1 - seeking feedback
Sent by:"openssl-dev" <openssl-dev-boun...@openssl.org>





On Mon, Nov 16, 2015 at 9:06 PM, Peter Waltenberg <pwal...@au1.ibm.com>
wrote:
  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.


This is an interesting idea. For completeness, it has failed in other
contexts. For example, the IETF's TLS Working Group refuses to provide such
an abstraction. See, for example,
https://www.ietf.org/mail-archive/web/tls/current/msg17611.html.
___
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] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

2015-11-16 Thread 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

2015-11-16 Thread 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

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

2015-11-16 Thread 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

2015-11-16 Thread 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 <openssl-us...@dukhovni.org>
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" <openssl-dev-boun...@openssl.org>



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