Open Stack

On Thu, 2013-04-25 at 15:41 +0000, Bhandaru, Malini K wrote:
> 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.

Your points apply well to the Key Manager case where encryption keys for
disk volumes are handled. For internal message queue security however
point 3 is simply not applicable.

And I will address point 1, 2 by making the algorithm a configuration
option in the implementation, however I will keep the language in the
current document, just read the "we choose X and Y algorithm" to simply
mean "as default".

What I am not going to do and will strongly object to is to add means to
negotiate algorithms. If you want to go down that rabbit hole we should
just stop trying to do our own and instead use an existing
implementation like Kerberos and simply build APIs on top of it so it
can be exposed via HTTP instead of the traditional stream oriented
GSSAPI.

Simo.

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