Open Stack

Ok, folks!

Per the IRC meeting this morning, we came to the following consensus
regarding how TLS certificates are handled, how SAN is handled, and how
hostname conflict resolution is handled. I will be responding to all three
of the currently ongoing mailing list discussions with this info:


   - Driver does not have to use SAN that is passed from API layer, but SAN
   will be available to drivers at the API layer. This will be mentioned
   explicitly in the spec.
   - Order is a mandatory attribute. It's intended to be used as a "hint"
   for hostname conflict resolution, but it's ultimately up to the driver to
   decide how to resolve the conflict. (In other words, although it is a
   mandatory attribute in our model, drivers are free to ignore it.)
   - Drivers are allowed to vary their behavior when choosing how to
   implement hostname conflict resolution since there is no single algorithm
   here that all vendors are able to support. (This is anticipated to be a
   rare edge case anyway.)

I think Evgeny will be updating the specs to reflect this decision so that
it is documented--  we hope to get ultimate approval of the spec in the
next day or two.

Thanks,
Stephen


On Wed, Jul 16, 2014 at 7:26 PM, Stephen Balukoff <sbalukoff at bluebox.net>
wrote:

> Hi Vijay,
>
>
>
> On Wed, Jul 16, 2014 at 9:07 AM, Vijay Venkatachalam <
> Vijay.Venkatachalam at citrix.com> wrote:
>
>>
>>
>> Do you know if the SSL/SNI IETF spec details about conflict resolution. I
>> am assuming not.
>>
>>
>>
>> Because of this ambiguity each backend employs its own mechanism to
>> resolve conflicts.
>>
>>
>>
>> There are 3 choices now
>>
>> 1.       The LBaaS extension does not allow conflicting certificates to
>> be bound using validation
>>
>> 2.       Allow each backend conflict resolution mechanism to get into
>> the spec
>>
>> 3.       Does not specify anything in the spec, no mechanism introduced
>> and let the driver deal with it.
>>
>>
>>
>> Both HA proxy and Radware uses configuration as a mechanism to resolve.
>> Radware uses order while HA Proxy uses externally specified DNS names.
>>
>> NetScaler implementation uses the best possible match algorithm
>>
>>
>>
>> For ex, let’s say 3 certs are bound to the same endpoint with the
>> following SNs
>>
>> www.finance.abc.com
>>
>> *.finance.abc.com
>>
>> *.*.abc.com
>>
>>
>>
>> If the host request is  payroll.finance.abc.com  we shall  use  *.
>> finance.abc.com
>>
>> If it is  payroll.engg.abc.com  we shall use  *.*.abc.com
>>
>>
>>
>> NetScaler won’t not allow 2 certs to have the same SN.
>>
>>
>>
>
> Did you mean "CN" as in "Common Name" above?
>
> In any case, it sounds like:
>
> 1. Conflicts are going to be relatively rare in any case
> 2. Conflict resolution as such can probably be left to the vendor. Since
> the Neutron LBaaS reference implementation uses HAProxy, it seems logical
> that this should be considered "normal" behavior for the Neutron LBaaS
> service-- though again the slight variations in vendor implementations for
> conflict resolution are unlikely to cause serious issues for most users.
>
> If NetScaler runs into a situation where the SCN of a cert conflicts with
> the SCN or SAN of another cert, then perhaps they can return an
> 'UnsupportedConfigruation' error or whatnot? (I believe we're trying to get
> the ability to return such errors with the flavor framework, correct?)
>
> In any case, is there any reason to delay going forward with a model and
> code that:
> A. Uses an 'order' attribute on the SNI-related objects to resolve name
> conflicts.
> B. Includes a ubiquitous library for extracting SCN and SAN that any
> driver may use if they don't use the 'order' attribute?
>
> Thanks,
> Stephen
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>



-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140717/26704731/attachment.html>