Re: [openstack-dev] [glance] [nova] Image Signature Verification
On 13/11/15 09:35 +, Daniel P. Berrange wrote: On Thu, Nov 12, 2015 at 08:30:53PM +, Poulos, Brianna L. wrote: 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. As well as not wanting MD5, I believe that computing signatures based on a configurable checksum in glance provides a bad user experiance. The user generating the signature of their image, now has to have a way to query glance to find out what checksum it used, in order to generate their signature. Further if the glance admin ever wants to change their checksum algorithm, they'd break all existing signatures by doing so. These are just as important reasons why I want Nova to use the 2nd option and compute signatures directly on the image content. This is a very good point. Thanks for bringing it up, Dan. 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. A second point about the current proposal from Nova's POV is that we do not like the image property names currently used. In Liberty Nova standardized on the property naming scheme it uses to have 3 naming prefixes https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L166 - 'hw_' - properties that affect virtual hardware configuration - 'os_' - properties that affect guest OS setup / configuration - 'img_' - properties that affect handling of images by the host The signature properties are obviously all related to the handling of images by the host, so from Nova's POV we should have an 'img_' prefix on all their names. We probably should have alerted glance devs to this naming convention before now to avoid this problem, but I guess we forgot. It would be great if glance devs could bear this preferred naming convention in mind if there are any future cases where there is a property that needs to be used by both Nova & Glance code. +1 Honestly, I wasn't aware there was such a convention. It's sad that we didn't know this before adding the signature field. Anyway since the change in the way we calculate signatures on images is a non-backwards compatible change for users of the current glance impl, changing these property names at this
Re: [openstack-dev] [glance] [nova] Image Signature Verification
On Tue, Nov 17, 2015 at 02:09:42PM -0300, Flavio Percoco wrote: > On 13/11/15 09:35 +, Daniel P. Berrange wrote: > >On Thu, Nov 12, 2015 at 08:30:53PM +, Poulos, Brianna L. wrote: > >>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. > > > >As well as not wanting MD5, I believe that computing signatures based > >on a configurable checksum in glance provides a bad user experiance. > >The user generating the signature of their image, now has to have a > >way to query glance to find out what checksum it used, in order to > >generate their signature. Further if the glance admin ever wants to > >change their checksum algorithm, they'd break all existing signatures > >by doing so. These are just as important reasons why I want Nova > >to use the 2nd option and compute signatures directly on the image > >content. > > This is a very good point. Thanks for bringing it up, Dan. > > > > >>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. > > > >A second point about the current proposal from Nova's POV is that > >we do not like the image property names currently used. In Liberty > >Nova standardized on the property naming scheme it uses to have 3 > >naming prefixes > > > > https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L166 > > > >- 'hw_' - properties that affect virtual hardware configuration > >- 'os_' - properties that affect guest OS setup / configuration > >- 'img_' - properties that affect handling of images by the host > > > >The signature properties are obviously all related to the handling > >of images by the host, so from Nova's POV we should have an 'img_' > >prefix on all their names. > > > >We probably should have alerted glance devs to this naming convention > >before now to avoid this problem, but I guess we forgot. It would be > >great if glance devs could bear this preferred naming convention in > >mind if there are any future cases where there is a
Re: [openstack-dev] [glance] [nova] Image Signature Verification
On 17/11/15 17:44 +, Daniel P. Berrange wrote: On Tue, Nov 17, 2015 at 02:09:42PM -0300, Flavio Percoco wrote: On 13/11/15 09:35 +, Daniel P. Berrange wrote: >On Thu, Nov 12, 2015 at 08:30:53PM +, Poulos, Brianna L. wrote: >>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. > >As well as not wanting MD5, I believe that computing signatures based >on a configurable checksum in glance provides a bad user experiance. >The user generating the signature of their image, now has to have a >way to query glance to find out what checksum it used, in order to >generate their signature. Further if the glance admin ever wants to >change their checksum algorithm, they'd break all existing signatures >by doing so. These are just as important reasons why I want Nova >to use the 2nd option and compute signatures directly on the image >content. This is a very good point. Thanks for bringing it up, Dan. > >>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. > >A second point about the current proposal from Nova's POV is that >we do not like the image property names currently used. In Liberty >Nova standardized on the property naming scheme it uses to have 3 >naming prefixes > > https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L166 > >- 'hw_' - properties that affect virtual hardware configuration >- 'os_' - properties that affect guest OS setup / configuration >- 'img_' - properties that affect handling of images by the host > >The signature properties are obviously all related to the handling >of images by the host, so from Nova's POV we should have an 'img_' >prefix on all their names. > >We probably should have alerted glance devs to this naming convention >before now to avoid this problem, but I guess we forgot. It would be >great if glance devs could bear this preferred naming convention in >mind if there are any future cases where there is a property that >needs to be used by both Nova & Glance code. +1 Honestly, I wasn't aware there was such a convention. It's
Re: [openstack-dev] [glance] [nova] Image Signature Verification
On Thu, Nov 12, 2015 at 08:30:53PM +, Poulos, Brianna L. wrote: > 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. As well as not wanting MD5, I believe that computing signatures based on a configurable checksum in glance provides a bad user experiance. The user generating the signature of their image, now has to have a way to query glance to find out what checksum it used, in order to generate their signature. Further if the glance admin ever wants to change their checksum algorithm, they'd break all existing signatures by doing so. These are just as important reasons why I want Nova to use the 2nd option and compute signatures directly on the image content. > 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. A second point about the current proposal from Nova's POV is that we do not like the image property names currently used. In Liberty Nova standardized on the property naming scheme it uses to have 3 naming prefixes https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L166 - 'hw_' - properties that affect virtual hardware configuration - 'os_' - properties that affect guest OS setup / configuration - 'img_' - properties that affect handling of images by the host The signature properties are obviously all related to the handling of images by the host, so from Nova's POV we should have an 'img_' prefix on all their names. We probably should have alerted glance devs to this naming convention before now to avoid this problem, but I guess we forgot. It would be great if glance devs could bear this preferred naming convention in mind if there are any future cases where there is a property that needs to be used by both Nova & Glance code. Anyway since the change in the way we calculate signatures on images is a non-backwards compatible change for users of the current glance impl, changing these property names at this point is reasonable todo. Glance could use the property name to determine whether it is getting an old or new style signature. ie if the
[openstack-dev] [glance] [nova] Image Signature Verification
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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
