Open Stack

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.
Regards
Malini

-----Original Message-----
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 
> >> [1]). 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 
> algorithms.

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.

--
Simo Sorce * Red Hat, Inc * New York


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev