On Jun 10, 2014, at 3:11 PM, Stephen Balukoff <sbaluk...@bluebox.net> wrote:
> Hi Evgeny, > > Comments inline. > > On Tue, Jun 10, 2014 at 4:13 AM, Evgeny Fedoruk <evge...@radware.com> wrote: > Hi All, > > > > Carlos, Vivek, German, thanks for reviewing the RST doc. > > There are some issues I want to pinpoint final decision on them here, in ML, > before writing it down in the doc. > > Other issues will be commented on the document itself. > > > > 1. Support/No support in JUNO > > Referring to summit’s etherpad > https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7, > > a. SNI certificates list was decided to be supported. Was decision made > not to support it? > Single certificate with multiple domains can only partly address the need for > SNI, still, different applications > on back-end will need different certificates. > > 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. I agree I think we should add SNI to the API at the very least even if we can not support it on the back end yet. > > I'm not sure I understand what you're proposing when you say "Single > certificate with multiple domains can only partly address the need for SNI, > still, different applications on back-end will need different certificates." I don't understand this either. We should support certificate chaining so that we can advertise the supplied chain to the users browser during the TLS handshake. > > 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. > > > b. Back-end re-encryption was decided to be supported. Was decision made > not to support it? > > 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. > > > c. With front-end client authentication and back-end server > authentication not supported, > Should certificate chains be supported? > > 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. > > 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. > > > 2. Barbican TLS containers > > a. TLS containers are immutable. > > b. TLS container is allowed to be deleted, always. > > i. Even > when it is used by LBaaS VIP listener (or other service). > > ii. Meta > data on TLS container will help tenant to understand that container is in use > by LBaaS service/VIP listener > > iii. 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? > > > So, there's other discussion of these points in previous replies in this > thread, but to summarize: > > * 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.) > > * 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. > > > > > Please comment on these points and review the document on gerrit > (https://review.openstack.org/#/c/98640) > > I will update the document with decisions on above topics. > > > I shall try to make sure I have time to review the document later today or > tomorrow. > > Stephen > > > > -- > Stephen Balukoff > Blue Box Group, LLC > (800)613-4305 x807 > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
