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

Michael D'Errico <> Fri, 30 October 2009 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3464B3A68AE for <>; Fri, 30 Oct 2009 12:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JwXHhH4y3NRl for <>; Fri, 30 Oct 2009 12:50:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D56E53A68B7 for <>; Fri, 30 Oct 2009 12:49:58 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 3A3EC6D685 for <>; Fri, 30 Oct 2009 15:50:15 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=2nLJacFXPzbC jzbze0kywFG17Ik=; b=tL3alV5AkSuy/E6u+8PR7rYIDqJ3orSroaFfADbXJ9Eh W2Fe8Aq9VRCaPumor+63vFpckdmmhT7mVAYer5F8KV1BMvKtWvOcMSWEQNi2NxbY DvC7UFWRwyQ/xuXhEa0RKredeKABuSO/yE6GyD/dGYRIY9EnRJS9z6bwYHjIsc0=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=PlihUW mYkg3pyy6vUB/h3rJecDx8neZyNFax4OvAv+9t0SD86Q7qxJhBXKPlNiWBDhHzMF meP83z/aoY13Z4cZYipq2qD3akih8qpzXUdvXQ5mixzumsiTEhjXx9E0r5tZkvBj ew4WPC4Lfz6J7NMhfKjt9HXSHX6D8yXlJwf1w=
Received: from a-pb-sasl-quonix. (unknown []) by (Postfix) with ESMTP id 371086D684 for <>; Fri, 30 Oct 2009 15:50:15 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9FC0A6D682 for <>; Fri, 30 Oct 2009 15:50:14 -0400 (EDT)
Message-ID: <>
Date: Fri, 30 Oct 2009 12:51:45 -0700
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 71704AFA-C58D-11DE-8925-1B12EE7EF46B-38729857!
Subject: Re: [TLS] Multiple domain names in SNI (was Questions about TLS
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Oct 2009 19:50:01 -0000

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

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

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