<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=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.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">We agree.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Evgeny will update probably on Sunday.<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""> Stephen Balukoff [mailto:sbalukoff@bluebox.net]
<br>
<b>Sent:</b> Thursday, June 19, 2014 10:23 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Samuel,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So at the LBaaS hackathon, Dustin, Carlos and I discussed order vs. hostname and we came to the conclusion that we'd be OK with order on the SNI list / SNI Policy, so long as we also make note that individual back-ends may choose to implement
this as a hostname hash lookup, based on hostnames embedded in the cert as the CN or x509v3 Subject Alternative Names.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In this case, then, we should specifically not make 'hostname' an attribute of the SNI list / SNI policy object because this information will be extracted by the driver / back-end implementation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think, though, we all still agree that supporting cipher selection criteria is probably beyond the scope of what we think we can reasonably offer in Juno. Back-ends should plan on using sane defaults for the first release, eh.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If you're in agreement with the above, could y'all update the spec, and we'll remove our '-1's? <a href="https://review.openstack.org/#/c/98640/">https://review.openstack.org/#/c/98640/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Stephen<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Jun 19, 2014 at 6:23 AM, Stephen Balukoff <<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal">Hi Samuel,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes, it's more friendly to extract this information on behalf of the user, but does occasionally break use cases we've seen. It should be possible, when there is hostname overlap, for the user to specify which certificate to use. It sounds
like the Radware solution uses certificate ordering to resolve this conflict.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">stunnel requires the user to specify which certs should be used with which hostnames, and I think balks if you try to repeat a hostname. So in stunnel's case, conflict resolution happens through user configuration.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So in both cases, the user specifies some way to do conflict resolution.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There's not a reason we couldn't do it the Radware way for stunnel. The algorithm would be:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1. Order configured certificates based on the 'order' attribute.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2. One by one in sequence, extract CN and Subject Alternative Names from the certificates.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3. If a conflict arises, do not allow certs later in the sequence to supersede / override hostnames set earlier in the sequence.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">However, I'm not sure it's possible to do the opposite (ie. "stunnel" way) for Radware and get exactly similar behavior.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">People should be aware that we are potentially catering to one vendor's needs here by adopting the above conflict resolution / certificate hostname extraction model.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In any case, it is probably still very handy to show the list of hostnames for which each certificate is valid to the user (ie. in UI's or whatever).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What do people think?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888">Stephen<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Jun 19, 2014 at 12:03 AM, Samuel Bercovici <<a href="mailto:SamuelB@radware.com" target="_blank">SamuelB@radware.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi Stephen,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The difference is whether the user get to specify hostnames or whether this get concluded from the
certificate.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I agree, that it might be more friendly if we have an immutable hostname field that get cached in
lbaas but being read from the certificate and not managed by the end user.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Sam.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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""> Stephen Balukoff [mailto:<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>]
<br>
<b>Sent:</b> Thursday, June 19, 2014 1:44 AM</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">So... what I'm hearing here is that we might want to support both a 'hostname' and 'order' attribute. Though exact behavior from vendor to vendor when there is name overlap is not
likely to be consistent.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Note that while we have seen that corner case, it is unusual... so I'm not against having slightly different behavior when there's name overlap from vendor to vendor.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Stephen<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Wed, Jun 18, 2014 at 2:15 PM, Samuel Bercovici <<a href="mailto:SamuelB@radware.com" target="_blank">SamuelB@radware.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif"">Hi Stephen,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif""> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif"">Radware Alteon extract the hostname information and the alt
<span style="background:white">subjectAltName</span> from the certificate information.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif"">It then do:</span><o:p></o:p></p>
<p><span style="font-family:"Calibri","sans-serif"">1.</span><span style="font-size:7.0pt">
</span><span style="font-family:"Calibri","sans-serif"">Find if there is exact match with the name in the https handshake and the ones extracted from the certificate, if there are more than a single match, the 1<sup>st</sup> one in the order will be used</span><o:p></o:p></p>
<p><span style="font-family:"Calibri","sans-serif"">2.</span><span style="font-size:7.0pt">
</span><span style="font-family:"Calibri","sans-serif"">If no match was found than try to use the regexp hostname to match, if you have multiple matches, the 1<sup>st</sup> one will be used</span><o:p></o:p></p>
<p><span style="font-family:"Calibri","sans-serif"">3.</span><span style="font-size:7.0pt">
</span><span style="font-family:"Calibri","sans-serif"">If no match was found than try to use
<span style="background:white">subjectAltName</span> to match. If you have multiple matches, the 1<sup>st</sup> one will be used</span><o:p></o:p></p>
<p><span style="font-family:"Calibri","sans-serif"">4.</span><span style="font-size:7.0pt">
</span><span style="font-family:"Calibri","sans-serif"">If no match than use default certificate</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif""> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif"">-Sam.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif""> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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""> Stephen Balukoff [mailto:<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>]
<br>
<b>Sent:</b> Thursday, June 19, 2014 12:03 AM</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi Evg,<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I do not think stunnel supports an "ordered list" without hostnames. Since we're talking about making the reference implementation use stunnel for TLS termination, then this seems
like it's important to support its behavioral model.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">It is possible to extract hostnames from the CN and x509v3 Subject Alternative Names in the certs, but, as has been discussed previously, these can overlap, and it's not always
reliable to rely on this data from the certs themselves. So, while I have nothing against having an ordered certificate list, stunnel won't use the order here, and stunnel will likely have unexpected behavior if hostnames are duplicated.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Would it work for Radware to simply order the (unique) hostnames alphabetically, and put any wildcard certificates at the end of the list?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Also, while I'm loathe to ask for details on a proprietary system: How does Radware do SNI *without* hostnames? Isn't that entirely the point of SNI? Client sends a hostname, and
server responds with the certificate that applies to that hostname?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Stephen<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Wed, Jun 18, 2014 at 8:00 AM, Evgeny Fedoruk <<a href="mailto:EvgenyF@radware.com" target="_blank">EvgenyF@radware.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi Stephen,<br>
Regarding your comment related to SNI list management and behavior in the RST document:<br>
<br>
I understand the need to explicitly specify specific certificates for specific hostnames.<br>
However we need to deliver lowest common denominator for this feature which every vendor is able to support<br>
In this case, specifying hostname for certificate will not be supported by Radware.<br>
The original proposal with ordered certificates list may be the lowest common denominator for all vendors and we should find out if this is the case.<br>
If not, managing a simple none-ordered list will probably be the lowest common denominator.<br>
<br>
With the proposed flavors framework considered, extra SNI management capabilities may be represented for providers<br>
but meanwhile we should agree on proposal that can be implemented by all vendors.<br>
What are your thought on this?<br>
<br>
Regarding the SNIPolicy, I agree and will change the document accordingly.<br>
<br>
Thanks,<br>
Evg<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Evgeny Fedoruk<br>
Sent: Sunday, June 15, 2014 1:55 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit<br>
<br>
Hi All,<br>
<br>
The document was updated and ready for next review round.<br>
Main things that were changed:<br>
1. Comments were addressed<br>
2. No back-end re-encryption supported<br>
3. Intermediate certificates chain supported<br>
*Opened question: Should chain be stored in same TLS container of the certificate?<br>
<br>
Please review<br>
Regards,<br>
Evgeny<br>
<br>
<br>
-----Original Message-----<br>
From: Douglas Mendizabal [mailto:<a href="mailto:douglas.mendizabal@RACKSPACE.COM" target="_blank">douglas.mendizabal@RACKSPACE.COM</a>]<br>
Sent: Wednesday, June 11, 2014 10:22 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit<br>
<br>
Hi Doug,<br>
<br>
<br>
Barbican does guarantee the integrity and availability of the secret, unless the owner of the secret deletes it from Barbican. We’re not encouraging that you store a shadow-copy of the secret either. This was proposed by the LBaaS team as a possible workaround
for your use case.<br>
Our recommendation was that there are two options for dealing with Secrets being deleted from under you:<br>
<br>
If you want to control the lifecycle of the secret so that you can prevent the user from deleting the secret, then the secret should be owned by LBaaS, not by the user. You can achieve this by asking the user to upload the secret via LBaaS api, and then use
Barbican on the back end to store the secret under the LBaaS tenant.<br>
<br>
If you want the user to own and manage their secret in Barbican, then you have to deal with the situation where the user deletes a secret and it is no longer available to LBaaS. This is a situation you would have to deal with even with a reference-counting
and force-deleting Barbican, so I don’t think you really gain anything from all the complexity you’re proposing to add to Barbican.<br>
<br>
-Douglas M.<br>
<br>
<br>
<br>
On 6/11/14, 12:57 PM, "Doug Wiegley" <<a href="mailto:dougw@a10networks.com" target="_blank">dougw@a10networks.com</a>> wrote:<br>
<br>
>There are other fundamental things about secrets, like relying on their<br>
>presence, and not encouraging a proliferation of a dozen<br>
>mini-secret-stores everywhere to get around that fact, which makes it<br>
>less secret. Have you considered a ³force² delete flag, required if<br>
>some service is using the secret, sort of ³rm² vs ³rm -f², to avoid the<br>
>obvious foot-shooting use cases, but still allowing the user to nuke it<br>
>if necessary?<br>
><br>
>Thanks,<br>
>Doug<br>
><br>
><br>
>On 6/11/14, 11:43 AM, "Clark, Robert Graham" <<a href="mailto:robert.clark@hp.com" target="_blank">robert.clark@hp.com</a>> wrote:<br>
><br>
>>Users have to be able to delete their secrets from Barbican, it's a<br>
>>fundamental key-management requirement.<br>
>><br>
>>> -----Original Message-----<br>
>>> From: Eichberger, German<br>
>>> Sent: 11 June 2014 17:43<br>
>>> To: OpenStack Development Mailing List (not for usage questions)<br>
>>> Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST<br>
>>> document on Gerrit<br>
>>><br>
>>> Sorry, I am late to the party. Holding the shadow copy in the<br>
>>> backend<br>
>>is a<br>
>>> fine solution.<br>
>>><br>
>>> Also, if containers are immutable can they be deleted at all? Can we<br>
>>make a<br>
>>> requirement that a user can't delete a container in Barbican?<br>
>>><br>
>>> German<br>
>>><br>
>>> -----Original Message-----<br>
>>> From: Eichberger, German<br>
>>> Sent: Wednesday, June 11, 2014 9:32 AM<br>
>>> To: OpenStack Development Mailing List (not for usage questions)<br>
>>> Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST<br>
>>> document on Gerrit<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> I think the previous solution is easier for a user to understand.<br>
>>> The referenced container got tampered/deleted we throw an error -<br>
>>> but keep existing load balancers intact.<br>
>>><br>
>>> With the shadow container we get additional complexity and the user<br>
>>might<br>
>>> be confused where the values are coming from.<br>
>>><br>
>>> German<br>
>>><br>
>>> -----Original Message-----<br>
>>> From: Carlos Garza [mailto:<a href="mailto:carlos.garza@rackspace.com" target="_blank">carlos.garza@rackspace.com</a>]<br>
>>> Sent: Tuesday, June 10, 2014 12:18 PM<br>
>>> To: OpenStack Development Mailing List (not for usage questions)<br>
>>> Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST<br>
>>> document on Gerrit<br>
>>><br>
>>> See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican<br>
>>> Neutron LBaaS Integration Ideas.<br>
>>> He's advocating keeping a shadow copy of the private key that is<br>
>>> owned<br>
>>by<br>
>>> the LBaaS service so that incase a key is tampered with during an LB<br>
>>update<br>
>>> migration etc we can still check with the shadow backup and compare<br>
>>> it<br>
>>to<br>
>>> the user owned TLS container in case its not their it can be used.<br>
>>><br>
>>> On Jun 10, 2014, at 12:47 PM, Samuel Bercovici <<a href="mailto:SamuelB@Radware.com" target="_blank">SamuelB@Radware.com</a>><br>
>>> wrote:<br>
>>><br>
>>> > To elaborate on the case where containers get deleted while LBaaS<br>
>>still<br>
>>> references it.<br>
>>> > We think that the following approach will do:<br>
>>> > * The end user can delete a container and leave a "dangling"<br>
>>> reference in LBaaS.<br>
>>> > * It would be nice to allow adding meta data on the<br>
>>container so that<br>
>>> the user will be aware which listeners use this container. This is<br>
>>optional. It<br>
>>> can also be optional for LBaaS to implement adding the listeners ID<br>
>>> automatically into this metadata just for information.<br>
>>> > * In LBaaS, if an update happens which requires to pull the<br>
>>container<br>
>>> from Barbican and if the ID references a non-existing container, the<br>
>>update<br>
>>> will fail and will indicate that the reference certificate does not<br>
>>exists any<br>
>>> more. This validation could be implemented on the LBaaS API itself<br>
>>> as<br>
>>well<br>
>>> as also by the driver who will actually need the container.<br>
>>> ><br>
>>> > Regards,<br>
>>> > -Sam.<br>
>>> ><br>
>>> ><br>
>>> > From: Evgeny Fedoruk<br>
>>> > Sent: Tuesday, June 10, 2014 2:13 PM<br>
>>> > To: OpenStack Development Mailing List (not for usage questions)<br>
>>> > Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST<br>
>>document<br>
>>> > on Gerrit<br>
>>> ><br>
>>> > Hi All,<br>
>>> ><br>
>>> > Carlos, Vivek, German, thanks for reviewing the RST doc.<br>
>>> > There are some issues I want to pinpoint final decision on them<br>
>>here, in<br>
>>> ML, before writing it down in the doc.<br>
>>> > Other issues will be commented on the document itself.<br>
>>> ><br>
>>> > 1. Support/No support in JUNO<br>
>>> > Referring to summit's etherpad<br>
>>> <a href="https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7" target="_blank">
https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7</a>,<br>
>>> > a. SNI certificates list was decided to be supported. Was<br>
>>decision made<br>
>>> not to support it?<br>
>>> > Single certificate with multiple domains can only partly address<br>
>>> > the need for SNI, still, different applications on back-end will<br>
>>> > need<br>
>>different<br>
>>> certificates.<br>
>>> > b. Back-end re-encryption was decided to be supported. Was<br>
>>decision<br>
>>> made not to support it?<br>
>>> > c. With front-end client authentication and back-end server<br>
>>> authentication not supported,<br>
>>> > Should certificate chains be supported?<br>
>>> > 2. Barbican TLS containers<br>
>>> > a. TLS containers are immutable.<br>
>>> > b. TLS container is allowed to be deleted, always.<br>
>>> > i.<br>
>>Even when it is used by LBaaS VIP<br>
>>> listener (or other service).<br>
>>> > ii.<br>
>>Meta data on TLS container will<br>
>>> help tenant to understand that container is in use by LBaaS<br>
>>service/VIP<br>
>>> listener<br>
>>> > iii.<br>
>>If every VIP listener will "register"<br>
>>> itself in meta-data while retrieving container, how that<br>
>>"registration" will be<br>
>>> removed when VIP listener stops using the certificate?<br>
>>> ><br>
>>> > Please comment on these points and review the document on gerrit<br>
>>> > (<a href="https://review.openstack.org/#/c/98640" target="_blank">https://review.openstack.org/#/c/98640</a>)<br>
>>> > I will update the document with decisions on above topics.<br>
>>> ><br>
>>> > Thank you!<br>
>>> > Evgeny<br>
>>> ><br>
>>> ><br>
>>> > From: Evgeny Fedoruk<br>
>>> > Sent: Monday, June 09, 2014 2:54 PM<br>
>>> > To: OpenStack Development Mailing List (not for usage questions)<br>
>>> > Subject: [openstack-dev] [Neutron][LBaaS] TLS support RST document<br>
>>on<br>
>>> > Gerrit<br>
>>> ><br>
>>> > Hi All,<br>
>>> ><br>
>>> > A Spec. RST document for LBaaS TLS support was added to Gerrit<br>
>>> > for review<br>
>>> > <a href="https://review.openstack.org/#/c/98640" target="_blank">https://review.openstack.org/#/c/98640</a><br>
>>> ><br>
>>> > You are welcome to start commenting it for any open discussions.<br>
>>> > I tried to address each aspect being discussed, please add<br>
>>> > comments<br>
>>> about missing things.<br>
>>> ><br>
>>> > Thanks,<br>
>>> > Evgeny<br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > OpenStack-dev mailing list<br>
>>> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><br>
><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">--
<br>
Stephen Balukoff <br>
Blue Box Group, LLC <br>
<a href="tel:%28800%29613-4305%20x807" target="_blank">(800)613-4305 x807</a> <o:p>
</o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">--
<br>
Stephen Balukoff <br>
Blue Box Group, LLC <br>
<a href="tel:%28800%29613-4305%20x807" target="_blank">(800)613-4305 x807</a> <o:p>
</o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Stephen Balukoff <br>
Blue Box Group, LLC <br>
<a href="tel:%28800%29613-4305%20x807" target="_blank">(800)613-4305 x807</a> <o:p>
</o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Stephen Balukoff <br>
Blue Box Group, LLC <br>
(800)613-4305 x807 <o:p></o:p></p>
</div>
</div>
</body>
</html>