Open Stack

-----Original Message-----
From: Luke Hinds <lhinds at redhat.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: November 18, 2016 at 08:43:42
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] Fwd: Re: [requirements][kolla][security] pycrypto vs cryptography

> Hi,
>  
> I missed this thread, so top posting with a related topic..
>  
> We discussed FIPS 140-2 yesterday in the OSSP irc meeting.
>  
> I recently tried running OpenStack on a FIPS 140-2 enabled kernel in
> CentOS, and all of instances of MD5 use (mainly hashlib.md5) were rejected
> resulting in the various python scripts bailing out with a stack trace. As
> someone pointed out already, MD5 is considered weak, and does not meet the
> FIPS list of secure crypto. I understand some projects might well use MD5
> for non security related functions, but when it comes to government
> compliance and running OpenStack on public clouds (and even private for the
> Telcos / NFV), not meeting FIPS will in some cases block production getting
> a green light, or at least make it a big challenge to push through.
>  
> With this in mind, perhaps all projects should seriously consider migrating
> to more up to date methods such as sha256 or bcrypt, and start to
> depreciate MD5 use.
>  
> I proposed raising bugs on launchpad for each instance discovered, so that
> if anything, we at least have an idea of the extent of work needed to reach
> the needed level of compliance for FIPS 140-2.
>  
> Thoughts welcome?

Well, are they or aren't they? ;)

So, specifically talking to MD5, this is a thing I've been trying to convince Glance to move away from for a while. The problem we have is that we need a strong migration path. I suspect part of the use of MD5 initially in Glance is due to its age (although we already knew MD5 was weak when Glance became its own project) and partially due to the fact that lots of operators used Swift as a Glance storage mechanism.

As for deprecating MD5 in favor of other hash algorithms, I don't think we should just jump to the a new algorithm (SHA2 or bcrypt) because, for one thing, only one of those you mentioned is FIPS compliant iirc (SHA2). For another, is a hash really what we want to judge the integrity of all data? Are there not better mechanisms for this? Blake2 would be good and has variations that are optimized for different hardware types (but it's almost certain not FIPS).

On top of that, what does the migration path look like for services that use the MD5 sum to verify properties and integrity internally and return that using the `Content-MD5` header? There's no replacement for that header in the 7230-7235 update of HTTP/1.1 and while we could make something up like `Content-SHA2` it probably will be confusing to users. (And no, using X-prefixed headers is no longer valid per RFCs and hasn't been for *years*.)

In short, I want to see us moving off MD5, but it will not be easy. I would bet that Glance and Swift will both be very resistant to this kind of change. We've had enough problems in Glance improving the usability of the *visibility* image attribute that I doubt we'd ever be able to migrate it to SHA2.

Also, instead of creating bugs, I would suggest instead that we try to make this into a community goal. We would work with the TC and for P or Q, make it a goal to start migrating off of MD5 and have a goal for a cycle or two later to completely remove reliance on MD5.

Doing this piecemeal via bugs will not be efficient and we'll need community buy-in.

--  
Ian Cordasco