Re: [openssl-users] [openssl-dev] 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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Richard Moore]

On 18 November 2015 at 17:57, Hubert Kario  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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Benjamin Kaduk]

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"
>  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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Does openssl server always choose highest TLS version offered?

[Jakob Bohm]

On 18/11/2015 00:25, Salz, Rich wrote:


ØI have seen rumors (nothing reliable) that the TLS WG is proposing
to disable a whole lot of good cipher suites in TLS 1.3.

Well, it’s pretty easy to verify.  Look at the IETF TLS-WG web page, 
and get a pointer to the current draft doc.


Yes, TLS removes non-AEAD ciphers, and has only PFS key exchange.



What I have seen of AEAD ciphers, they tend to be designed
right "at the margin" in terms of security, compared to
traditional combinations of one MAC algorithm with a
different encryption algorithm, where the different
algorithms tend to protect each other against many attacks.

The recent NSA notes on post-suite B and quantum-resistant
algorithms reminds us that all of the PFS key exchanges (DH
and ECDH) available are vulnerable to decryption of
wiretapped (recorded) transmissions once a real quantum
computer is built by anyone.  So are the other public key
exchange algorithms in TLS, but not the PSK algorithms
without PFS.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] 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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users