Re: [TLS] Multiple domain names in SNI (was Questions about TLS

[Michael D'Errico <[e-mail]>]

>> They could share IP addresses.
> 
> You mean that you client performs DNS-lookup for both names,
> determines that they point to the same IP-Address and then
> decides to address a single request for both?
> 
> How many HTTP Host: Header fields is your client going to send,
> and is the semantics for the server defined what to do with
> multiple Host: header fields.  We also didn't cover this in
> the revised text that urges an application to cross-check
> SNI vs. Host: Header fields.
> 
> JUST DON'T DO IT.

I was merely trying to come up with a possible scenario in which
you could hypothetically send two hostnames in the SNI extension,
not that I actually do that.  The important point is the following:

>> But the point is that you and I don't know for certain that there is
>> no possible requirement for a client to send multiple hostnames, so
>> imposing a limitation of only one hostname could preclude some future
>> application from being able to use TLS (without modifications or
>> private agreement).
> 
> We should not try to fix a problem before we even know that there is a
> problem (with limiting ServerNameList to unique members of each NameType).

People ARE trying to "fix" the extension by imposing a restriction
that is not currently present in the spec.  I maintain that there
is no savings of effort implementing the spec as is, versus imposing
a one-name-per-name-type restriction.

You still need to iterate through the list (since you may not recognize
the first name type), and look up the names of types you do recognize.
To implement one-name-per-name-type, you need to add a "break" statement
to stop processing the list once a lookup failure occurs.  So the code
to implement one-name-per-name type is actually MORE WORK than doing
it the way the spec is written today.  Oh, and you now have a bug since
you broke out of the loop before finding all the other name types in the
list.

>> If it was hard to implement checking for a match in a list, I'd agree
>> with you, but literally it is a simple while loop that calls your
>> lookup function for each name in the SNI extension.
> 
> Past experience regularly demonstrates that this is going to result
> in broken implementations.
> 
> Take the list of client ciphersuites in the ClientHello message for
> example.  It was hard to believe for me that there would be broken
> SSL/TLS Servers out there that used the ordering/preference of
> the ciphersuites in the ClientHello instead of the preference
> of the server to pick a common ciphersuites.  At a minimum,
> the precendence of the servers preferences over the clients
> should be configurable with the servers preferenca/configuration
> being the default.

The client ultimately overrules the server since it only has to offer
those cipher suites it is willing to negotiate.  The server can choose
whichever it likes, but only from the list it receives.  A client can
send a single cipher suite if it desires only that one.

> A hardcoded "clients list takes precedence" or a default for this
> indicates that the implementor didn't think about the security
> implications and may have been to easily misguided by obviously
> suboptimal wording in the specification.

I don't see any issue other than performance.  A server will simply
refuse to negotiate any cipher suite that doesn't match its security
needs.  If it negotiates RSA_WITH_RC4_MD5 and that doesn't provide
enough security, then whoever configured the list of allowable cipher
suites can only blame themselves, not the client.

> Every spec contains errors and suboptimal or misleading wording.
> It's _MUCH_ easier to realize the problems when trying to implement
> a spec.  So when implementing specs, it is very important to
> use common sense when reading it and strive for consistent
> and predictable behaviour.

I've implemented lots of specs, so I agree with you that clarity is
important.  It is just as easy to say, "Note: there may be any number
of names of a particular name type" as it is to say, "There MUST NOT
be more than one name of a particular name type."

If the more restrictive version led to considerably simpler coding,
I'd readily agree with changing it, but as I've pointed out above,
there is no simplification of the code.

Mike