<div dir="ltr">Hi Evgeny,<div class="gmail_extra"><br></div><div class="gmail_extra">Comments inline.<br><br><div class="gmail_quote">On Tue, Jun 10, 2014 at 4:13 AM, Evgeny Fedoruk <span dir="ltr"><<a href="mailto:EvgenyF@radware.com" target="_blank">EvgenyF@radware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Hi All,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Carlos, Vivek, German, thanks for reviewing the RST doc.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">There are some issues I want to pinpoint final decision on them here, in ML, before writing it down in the doc.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Other issues will be commented on the document itself.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p><u></u><span style="color:rgb(31,73,125)"><span>1.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span dir="LTR"></span><span style="color:rgb(31,73,125)">Support/No support in JUNO<u></u><u></u></span></p>
<p><span style="color:rgb(31,73,125)">Referring to summit’s etherpad
<a href="https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7" target="_blank">https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7</a>,
<u></u><u></u></span></p>
<p style="margin-left:1in">
<u></u><span style="color:rgb(31,73,125)"><span>a.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span dir="LTR"></span><span style="color:rgb(31,73,125)">SNI certificates list was decided to be supported. Was decision made not to support it?<br>
Single certificate with multiple domains can only partly address the need for SNI, still, different applications
<br>
on back-end will need different certificates.</span></p></div></div></blockquote><div>SNI support is a "show stopper" for us if it's not there. We have too many production services which rely on SNI working for us not to have this feature going forward.</div>
<div><br></div><div>I'm not sure I understand what you're proposing when you say "<span style="color:rgb(31,73,125)">Single certificate with multiple domains can only partly address the need for SNI, still, different applications</span><span style="color:rgb(31,73,125)"> </span><span style="color:rgb(31,73,125)">on back-end will need different certificates."</span></div>
<div><span style="color:rgb(31,73,125)"><br></span></div><div>In order to "fully" support SNI, you simply need to be able to specify alternate certificate/key(s) to use indexed by the hostname with which the non-default certificate(s) correspond. And honestly, if you're going to implement TLS termination support at all, then adding SNI is a pretty trivial next step.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">
<div><p style="margin-left:1in"><span style="color:rgb(31,73,125)"><u></u><u></u></span></p>
<p style="margin-left:1in">
<u></u><span style="color:rgb(31,73,125)"><span>b.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span dir="LTR"></span><span style="color:rgb(31,73,125)">Back-end re-encryption was decided to be supported. Was decision made not to support it?</span></p></div></div></blockquote><div>So, some operators have said they need this eventually, but I think the plan was to hold off on both re-encryption and any kind of client certificate authentication in this release cycle. I could be remembering the discussion on this incorrectly, though, so others should feel free to correct me on this.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">
<div><p style="margin-left:1in"><span style="color:rgb(31,73,125)"><u></u><u></u></span></p>
<p style="margin-left:1in">
<u></u><span style="color:rgb(31,73,125)"><span>c.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span dir="LTR"></span><span style="color:rgb(31,73,125)">With front-end client authentication and back-end server authentication not supported,
<br>
Should certificate chains be supported?</span></p></div></div></blockquote><div>Certificate chains are a different beast entirely. What I mean by that is: Any given front-end (ie. "server") certificate issued by an authoritative CA today may need intermediate certificates supplied for most browsers to trust the issued certificate implicitly. (Most do, in my experience.) Therefore, in order to effectively do TLS offload at all, we need to be able to supply an intermediate CA chain which will be supplied with the server cert when a client connects to the service.</div>
<div><br></div><div>If you're talking about the CA bundle or chain which will be used to verify client certificates when we offer that feature... then no, we don't need that until we offer the feature.</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div>
<p style="margin-left:1in"><span style="color:rgb(31,73,125)"><u></u><u></u></span></p>
<p><u></u><span style="color:rgb(31,73,125)"><span>2.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span dir="LTR"></span><span style="color:rgb(31,73,125)">Barbican TLS containers
<u></u><u></u></span></p>
<p style="margin-left:1in">
<u></u><span style="color:rgb(31,73,125)"><span>a.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span dir="LTR"></span><span style="color:rgb(31,73,125)">TLS containers are immutable.<u></u><u></u></span></p>
<p style="margin-left:1in">
<u></u><span style="color:rgb(31,73,125)"><span>b.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span dir="LTR"></span><span style="color:rgb(31,73,125)">TLS container is allowed to be deleted, always.<u></u><u></u></span></p>
<p style="margin-left:1.5in">
<u></u><span style="color:rgb(31,73,125)"><span><span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span>i.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><u></u><span dir="LTR"></span><span style="color:rgb(31,73,125)">Even when it is used by LBaaS VIP listener (or other service).<u></u><u></u></span></p>
<p style="margin-left:1.5in">
<u></u><span style="color:rgb(31,73,125)"><span><span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span>ii.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><u></u><span dir="LTR"></span><span style="color:rgb(31,73,125)">Meta data on TLS container will help tenant to understand that container is in use by LBaaS service/VIP listener<u></u><u></u></span></p>
<p style="margin-left:1.5in">
<u></u><span style="color:rgb(31,73,125)"><span><span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span>iii.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><u></u><span dir="LTR"></span><span style="color:rgb(31,73,125)">If every VIP listener will “register” itself in meta-data while retrieving container, how that “registration” will
be removed when VIP listener stops using the certificate?</span></p></div></div></blockquote><div><br></div><div>So, there's other discussion of these points in previous replies in this thread, but to summarize:</div>
<div><br></div><div>* There are multiple strategies for handling barbican container deletion, and I favor the one suggested by Adam of creating "shadow" versions of any referenced containers. I specifically do not like the one which allows for dangling references, as this could mean the associated listener breaks weeks or months after the barbican container was deleted (assuming no eventing system is used, which it sounds like people are against.)</div>
<div><br></div><div>* Meta data on container is a good idea, IMO. Perhaps we might consider simply leaving "generic" meta-data which is essentially a note to the barbican system, or any GUI referencing the cert to check with the LBaaS service to see which listeners are using the cert? This wouldn't need to be cleaned up, because if the container actually isn't in use by LBaaS anymore, then LBaaS would simply respond that nothing is using the cert anymore.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div>
<p style="margin-left:1.5in"><span style="color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Please comment on these points and review the document on gerrit (</span><a href="https://review.openstack.org/#/c/98640" target="_blank">https://review.openstack.org/#/c/98640</a><span style="color:rgb(31,73,125)">)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">I will update the document with decisions on above topics.</span></p></div></div></blockquote><div><br></div><div>I shall try to make sure I have time to review the document later today or tomorrow.</div>
<div><br></div><div>Stephen</div><div><br></div><div><br></div></div><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div></div>