Open Stack

On Jun 10, 2014, at 3:11 PM, Stephen Balukoff <sbalukoff at bluebox.net> wrote:

> Hi Evgeny,
> 
> Comments inline.
> 
> On Tue, Jun 10, 2014 at 4:13 AM, Evgeny Fedoruk <EvgenyF at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev