On 16/11/2015 16: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. > > 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. > > - 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. There is also the point that OpenSSL is the worlds most well known "Swiss army knife" crypto package for non-research uses. The more you overfocus on the single SSL/TLS use case, the less attractive OpenSSL becomes to all other uses. If OpenSSL makes itself useless, others will have to reinvent it. > > - I believe that the OpenSSL community generally tends to overlook the > positive impact of change when trying to round up the negative impact > of breakage. Applications are generally able to move along and fix > things when presented with the right incentives. Applications that > aren't generally able to move along are rather unlikely to jump onto > OpenSSL 1.1, and all these algorithms will be supported as part of > OpenSSL 1.0.2 until 2020 for them. Finally, removing support for these > algorithms from OpenSSL doesn't render your encrypted storage > inaccessible. You can always use another implementation to > decrypt/re-encrypt your data, and I fully believe in the power of the > community in providing such tools where necessary. > > - Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty > widespread MySQL breakage. That made MySQL backport a change > increasing the DH key length from 512 to 2048 bits. For end user > security, it's a win. I would prefer that we start cashing in these > improvements before the next Logjam happens. (This is my view; as you > can see views differ even within the team.) The Logjam protection was an SSL-only change. It has NO relevance to the deleterious effects of crippling the non-SSL functionality in the OpenSSL libraries. > > - On binary elliptic curves: with recent cryptographic advances, I > believe these are now firmly planted in the "internet archive" > category, even if not practically broken yet. The other reason for > removing these is that our implementations are crappy. They're not > constant-time, and they've been shown to contain bugs. Improving upon > these implementations is not a good use of dev time imo, given their > decreasing credibility. > > Here's the list of algorithms gone from BoringSSL: > > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves > > This isn't of course entirely representative of widespread usage. > However Google's multi-billion line codebase now builds against > BoringSSL and therefore largely does not depend on these algorithms. > Those billions of lines aren't all new and shiny code written in 2015, > and some of it does have to interoperate with the outside world. > > And here's the list gone from LibreSSL, from what I can tell: > > MD2, MDC2, RC5, SEED > > Neither have removed CAST, and there is presumably a good reason for > that. (PGP?) > > 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.) Please read my description again. I was arguing that the disabling of signature checking done in OpenSSL 1.0.0 was a mistake and is really a security-weakening bug. As that bug is fixed (by reinstating, in general, the checking of the self-signature on root certificates), the problem with MD2 being disabled completely (rather than being marked as untrusted) will resurface, at least for data at rest (prime *example* is CMS signed e-mail and files signed with certificates that trace back to the original Verisign root). > MDC2 > SEED > RC5 > > These could probably stay (C only): > > CAST > IDEA > RIPEMD (used in Bitcoin?) > WHIRLPOOL > > as well as > > BLOWFISH > MD4 > RC2 > > I am on the fence about the binary curves: I am not aware of any > usage, really, and it's not about to pick up now. > > Cheers, > Emilia > > On Mon, Nov 16, 2015 at 2:21 PM, Hubert Kario <hkario at redhat.com > <mailto:hkario at redhat.com>> wrote: > > On Friday 13 November 2015 14:40:33 Emilia K?sper wrote: > > Hi all, > > > > We are considering removing from OpenSSL 1.1 known broken or > outdated > > cryptographic primitives. As you may know the forks have already > done > > this but I'd like to seek careful feedback for OpenSSL first to > > ensure we won't be breaking any major applications. > > > > These algorithms are currently candidates for removal: > > > > CAST > > IDEA > > MDC2 > > MD2 [ already disabled by default ] > > RC5 [ already disabled by default ] > > RIPEMD > > SEED > > WHIRLPOOL > > ALL BINARY ELLIPTIC CURVES > > > > My preference would be to remove these algorithms completely (as in, > > delete the code). Disabled-by-default code will either be re-enabled > > by distros (if there's widespread need for it - in which case we > > might as well leave it in) or will be poorly tested and is likely to > > just silently rot and break. This code is bloat and maintentance > > burden for us - my hope is that much of this code is effectively > dead > > and can be removed. > > > > *Are you aware of any mainstream need to continue supporting these > > algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or > > binary, or a standalone implementation or another crypto toolkit can > > always be used to continue supporting a legacy standalone > > application, or to decrypt ciphertext from the distant past. I am > > looking for use cases that could cause e.g. interop breakage between > > new and old peers, or major pain to distro end-users. > > > > These algorithms are obsolete but removing them doesn't look > feasible: > > > > BLOWFISH - probably still in use though I don't know where exactly? > > MD4 - used in NTLM > > RC2 - used in PKCS#12 > > > > *Did I miss anything from the list?* > > I'd say that this is the wrong approach. > > If you have old stuff signed with MD2, and then timestamped with MD5, > SHA-1, SHA-256 over the years, with new timestamp added every year > this > makes the MD2 signature _valid_ and _secure_. > > If you have stuff that is encrypted, but in deep storage with any of > those algorithms, then yes, it's less than optimal. Removing > support for > those algorithm will make this data inaccessible. Not to mention that > stuff like IDEA or SEED may never get broken before the data in them > needs to remain secret - and after that creating a new archive with > unencrypted data after it can become public would simply cost money. > > And as some pointed out, few OpenSSL users actually read mailing > lists, > fewer still know what actual primitives are necessary for their > stuff to > work (e.g. PKCS#8 files specify inside them the cipher and key > derivation necessary for decryption). > > > What I think is the correct course of action, is to have in the > configuration file settings which specify the set of algorithms > that are > set as available and trusted. So that we can disable them by > default and > require the users to make a concious decision to enable support for > them. (Make openssl print to stderr info about them being > administratively disabled when application tries using them for bonus > points). > > This allows to place the information about this depreciation in a > place > where users will actually see it and will make them concious of using > weak and badly tested algorithms. At the same time it will protect > most > of the users that don't require such obsolete algorithms. > > But this concious decision MUST NOT require recompilation of the > package. Few if any distributions support recompiled packages. For > many > end-users this is also a hurdle they simply can't cross. > > And this also allows openssl to change the cryptographic policy in > stable branches without breaking the API/ABI promise. (POODLE, FREAK, > Logjam) > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151116/6b199c81/attachment-0001.html>
