[openstack-dev] [nova][keystone] Message Queue Security
Bhandaru, Malini K
malini.k.bhandaru at intel.com
Thu Apr 25 15:41:02 UTC 2013
My take on encryption choice:
1) Not giving choice when it exists is bad. We especially do not want our solution to be disregarded because of its restrictiveness.
2) The novice user/deployer/enterprise can be agnostic of the crypto choices, the defaults being set to NIST best practices.
3) Billing -- encrypted/un-encrypted rates will differ, and a 1024 bit key encryption would be more expensive than a 256 bit key.
A small deployer may want to give their public web pages un-encrypted but their high value customer/pay-roll data strongly encrypted and with different strengths may be. Sometimes in retail, the winner of a contract may differ in price point by just a cent. This choice affords both user and cloud provider different monitization rates. I am thinking for object/volume encryption here, not openstack endpoint to endpoint communication.
There we can keep things fixed, best practice.
From: Simo Sorce [mailto:simo at redhat.com]
Sent: Thursday, April 25, 2013 7:51 AM
To: David Chadwick
Cc: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [nova][keystone] Message Queue Security
On Thu, 2013-04-25 at 15:38 +0100, David Chadwick wrote:
> On 25/04/2013 14:51, Simo Sorce wrote:
> > On Thu, 2013-04-25 at 09:20 -0400, Davanum Srinivas wrote:
> >> Simo,
> >> Nice! feedback after a quick browse and compare with xml-dsig
> >> 1. Can we please allow additional algorithms? (see DigestMethod in
> >> ). HMAC-SHA-256 can definitely be the default
> > Well as a principle I like keeping security code *simple* and well
> > defined, at least for an initial implementation. We might add
> > additional metadata in the future to specify different algorithms,
> > but I would see that as an additional feature to allow in the future.
> I think you should differentiate between the code that implements
> different algorithms, and the mechanism that is used to choose between
The problem is that crypto is hard, and considering all the implications of how algorithms interact is something few can master.
so I tend to subscribe to the cabal :) that wants to dictate a very strict set and not give much choice to the implementer when it comes to how crypto is handled.
So my question really is: why do you want choice in this matter ?
> The initial implementation should not be hard coded with any specific
> algorithm, but should have the mechanism for choosing between
> algorithms built into it from the start,
I object in principle to this :)
> even if the initial
> implementation only supports one algorithm. It then becomes relatively
> straight forward to plug in new algorithms.
Yes, which is not necessarily a good thing. I am not saying we will not end up doing this, but I want to hear a good reason for allowing non-experts (ie the users or the packagers) choice in this matter.
The more options you add the more avenues of attack you add ...
Simo Sorce * Red Hat, Inc * New York
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev