Open Stack

Hello,

There has recently been additional discussion about the best way to handle
image signature verification in glance and nova [1].  There are two
options being discussed for the signature (the examples below using
'RSA-PSS' as the type, and SHA-256 as the hash method):

1. The signature is of the glance checksum of the image data (currently a
hash which is hardcoded to be MD5)
signature = RSA-PSS(SHA-256(MD5(IMAGE-CONTENT)))

2. The signature of the image data directly
signature = RSA-PSS(SHA-256(IMAGE-CONTENT))

The 1st option is what is currently in glance's liberty release [2].  This
approach was chosen with the understanding that the glance checksum would
be updated to be configurable [3].  Although the 2nd option was initially
proposed, the glance community opposed it during the pre-Liberty virtual
mini-summit in May 2015 (due to the performance impact of doing two hashes
of the image data--one for the 'checksum' and the other for the
signature), and it was decided to proceed with the 1st option during the
Liberty summit [4].

During the Mitaka Summit, making the glance checksum configurable was
discussed during a design session [5].  It was decided that instead of
making the 'checksum' image field configurable, it would be preferable to
compute a separate, configurable (on a per-image basis, with a site-wide
default) hash, and then use that hash when MD5 wasn't sufficient (such as
in the case of signature verification). This second hash would be computed
at the same time the MD5 'checksum' was computed.

Which brings us to the nova spec which is under discussion [1], which is
to add the ability to verify signatures in nova.  The nova community has
made it clear that the promise of providing a configurable hash in glance
is not good enough--they never want to support any signatures that use MD5
in any way, shape, or form; nor do they want to rely on asking glance for
what hash option was used.  To that end, the push is to use the 2nd option
to verify signatures in nova from the start.

Since the glance community no longer seems opposed to the idea of
computing two hashes (the second hash being optional, of course), the 2nd
option has now become valid from the glance perspective.  This would
require modifying the existing implementation in glance to verify a
signature of the image data, rather than verifying a checksum of the image
data, but would have no additional performance hit beyond the cost to
compute the second hash.  Note that the image data would still only be
read once -- the checksum update (for the MD5 hash) and the signature
verification update (for the signature hash) would occur in the same loop.
Although this would mean that signatures generated using option 1 would no
longer verify, since signatures generated using option 1 are based on an
MD5 hash (and were waiting for the checksum configurability before
becoming a viable cryptographic option anyway), this does not pose a
significant issue.

Also note that the verification in glance is provided as a benefit to the
user, so that the user can know that the signature properties were defined
correctly at upload, rather than having to wait until the image is booted
by nova to see a signature verification fail due to an improperly-defined
signature property.  However, the main purpose of the image signature
verification feature is to provide a guarantee between when a user signs
it and when nova boots it, and so it is more important to have the
verification occur in nova.

It would be beneficial to have a consistent approach between both the nova
and glance projects (and any future projects that make use of signature
verification).  Otherwise, the feature is not likely to be used by anyone.

Is anyone opposed to proceeding with using option 2, in both glance and
nova?  


[1] 
https://review.openstack.org/#/c/188874/19/specs/mitaka/approved/image-veri
fication.rst
[2] 
http://specs.openstack.org/openstack/glance-specs/specs/liberty/image-signi
ng-and-verification-support.html
[3] https://review.openstack.org/#/c/191542/
[4] 
https://etherpad.openstack.org/p/liberty-glance-image-signing-and-encryptio
n
[5] 
https://etherpad.openstack.org/p/mitaka-glance-image-signing-and-encryption

Thanks,
~Brianna