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

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> 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.


> 
> 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).


> 
> 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.


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.


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.


-Martin