<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Good point John! De-duplication/compression is a no-win on an encrypted object.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Prior to archiving, compression, then encryption, and save.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">A volume in active use would just be encrypted, but prior to detach, compress, encrypt and archive in Swift or some other backing store.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Malini<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> John Griffith [mailto:john.griffith@solidfire.com]
<br>
<b>Sent:</b> Thursday, February 14, 2013 11:43 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Cc:</b> Nate Reller<br>
<b>Subject:</b> Re: [openstack-dev] Volume Encryption<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Feb 14, 2013 at 10:38 AM, Caitlin Bestler <<a href="mailto:caitlin.bestler@nexenta.com" target="_blank">caitlin.bestler@nexenta.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On 2/14/2013 8:23 AM, Nate Reller wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Malini, I was happy to learn about a key manager discussion at the summit. Do you know what track this would be under? I can't decide if this should be in Keystone or maybe a whole new service. I like the idea of a whole new service
myself because I think it helps to have the separation and prevent bloating of functionality for components. On the other hand, I probably don't want a dozen services.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I like the idea of the key-id. I think we may end up using that idea. This will help us to support snapshot operations.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">One item we have yet to tackle is cloning. I think there are a few options for this.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1) Don't support clone operations for encrypted volumes. This is easy to implement and prevents key reuse, but it limits functionality.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2) Support clone with same key. This should be easy to implement as well. We could use the metadata key-id and set it to the same value for the clone. The drawback to this is that the key has multiple uses, and it could be used to decrypt
many different volumes. I don't like the idea of that. If the key is compromised then what do you do?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3) Support clone with different key. You could do this by decrypting the bytes from the original volume and encrypting them with a new key. If we are going to support cloning then I think I like this approach the best. The drawback on
this is time.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There are similar issues for snapshots, but I am not as opposed to option 2 for snapshots. Any thoughts on this?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-Nate<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-family:"Arial","sans-serif"">
<hr size="1" width="100%" align="center">
</span></div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Great outline, it zeroes in on the most critical issue.<br>
<br>
Nexenta favors option 2, which shouldn't be surprising since we on-the-fly snapshotting and cloning<br>
is one of the key strengths of ZFS.<br>
<br>
When you have to decrypt and re-encrypt a volume the process is no longer a "snapshot", but something<br>
that resembled Civil War era photography.<br>
<br>
However, I do not see Keystone as being a key repository that is up to supporting distributed keys.<br>
Any would-be attacker would immediately target the encryption of communicating with keystone<br>
as being a far more vulnerable target than the encryption used on the volumes themselves.<br>
<br>
I believe what we need is to allow the encryption keys to be stored by the storage servers themselves<br>
in secure lock boxes, and the role of OpenStack should be to authorize secure transfers between those<br>
lockboxes (which could be encrypted by far more than SSL).<br>
<br>
<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
<p class="MsoNormal">I've been pretty much silent through most of this discussion and I'm fine with the direction everybody's taking here. The concerns that I had regarding the implementation itself; I raised in the review for the code and the responses/solution
were addressed so I don't have a problem.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I just want to urge folks to make sure we document this VERY well. There are all sorts of corner cases, caveats etc that this has the potential to raise. For example, if somebody is using a back-end device that has internal encryption
features, then you turn around and try to overlay the nova encryption changes on top of it. The absolute destruction that this will cause on some de-duplication algorithms depending again on the back-end.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I really could care less about what algorithm is used etc, I think the folks involved in this thread have plenty of expertise in this area and I leave that up to them. I just think as has been pointed out we need to stress via documentation
and communication to folks that there are significant risks and possible issues if they choose to turn this on without a good understanding of exactly how it works etc.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">John<o:p></o:p></p>
</div>
</div>
</body>
</html>