Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
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
Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
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] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
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
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] Does openssl server always choose highest TLS version offered?
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