Re: [TLS] Multiple domain names in SNI (was Questions about TLS Server Name Indication extension)

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96D6E3A682B for <>; Fri, 30 Oct 2009 09:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_55=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cRE4bo-bbJhG for <>; Fri, 30 Oct 2009 09:19:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6BD8F3A682A for <>; Fri, 30 Oct 2009 09:19:20 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 9C2C16D1A7 for <>; Fri, 30 Oct 2009 12:19:34 -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=W8rzr5j6HrUa 60DQh5wEmr2nIrE=; b=XlUioTFtlLnQjWXBLxGWn5CkCmfpC+aZrgelHdSjZ1yC yWDUx24tYplFHDX3knC4s0BjLgS1DBViS1WGJglZiBet5SLogdo1Ea3sx3toiUIf 9hXLQ63uISeRITSI6JvdbyJyMK+9XsKXYEuCFhbotVv298wwiwa/JOQPuzjaCBQ=
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=Pm+hKM 3zT1cRSq7e1MRojARo2j0zFxexneQpmP14SXrkL0NzSOX46QSANJ6DTtX9s1hk5Q 1+YQa7opPkvaVHeXcxfBccJW0YXFp4m836qQduoXXLAtR3LdofGKzDOoZaYW2dOG r0dh5X/SRNHVE/sztjc3ltFtvDt0BHFTu2qlM=
Received: from a-pb-sasl-quonix. (unknown []) by (Postfix) with ESMTP id 993816D1A6 for <>; Fri, 30 Oct 2009 12:19:34 -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 21B396D1A5 for <>; Fri, 30 Oct 2009 12:19:33 -0400 (EDT)
Message-ID: <>
Date: Fri, 30 Oct 2009 09:21:03 -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: 030E2608-C570-11DE-AED6-1B12EE7EF46B-38729857!
Subject: Re: [TLS] Multiple domain names in SNI (was Questions about TLS Server Name Indication extension)
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 16:19:22 -0000

Here's a possible reason for a client to include multiple domain
names in the SNI.  Suppose a user enters "" into their
browser.  The browser may decide to send the two names ""
and also "" to the server in an attempt to connect on
the first try, rather than get rejected on the first connection
and have the overhead of retrying.

Even if you disagree that that is a possible scenario, if you want
to restrict what you can do with a protocol there should be a good
reason to do it.  Either it must present a security issue, or it
must cause undue burden on implementers for no benefit.  I don't
see how it is a security issue for the server to look up more than
one name, and there is no burden in adding a simple loop to look
up those names sequentially.  In fact, you already need the loop
to skip any name types you don't recognize, so the issue is whether
you put a break statement in your loop or not.


Nelson B Bolyard wrote:
> On 2009-10-28 17:04 PDT, Michael Gray wrote:
>> <> wrote:
>>> Consider this scenario:
>>> Physical host has two virtual hosts, A and B.
>>> First handshake:
>>>   client sends SNI with host name A, empty session ID.
>>>   server does full handshake, session ID 1.
>>> Second handshake (renegotiation):
>>>   client sends SNI with host name B and session ID 1,
>>> Session ID 1 implicitly identifies host A.
>>> The server could
>>> A)  Honor the session ID and ignore the SNI.
>>> B)  Compare the host name in the SNI with the host name for session ID 1,
>>>     observe the mismatch, and do a new FULL handshake for host B.
>>> C)  Compare the host name in the SNI with the host name for session ID 1,
>>>     observe the mismatch, and return a fatal error alert.
>>> RFC 5246 seems to suggest choice A.  It says:
>>>    Most current TLS extensions are relevant only
>>>    when a session is initiated: when an older session is resumed, the
>>>    server does not process these extensions in Client Hello, and does
>>>    not include them in Server Hello.
>>> But I tend to lean towards choice B myself.
>>> What do other SNI server implementations do in this case?
>> A for IBM native SSL.  The Client SNI data is only processed if the session
>> can NOT be resumed.
>> Also as an answer to the previous question; we only consider that the
>> Client has sent a single name in Client SNI request.
> Thanks, Mick, for those concise answers.  Sadly, I don't sense that we
> have a consensus from among the responses yet, except on the point that
> the SNI client hello should only contain one name of each type.
> I think that interoperability demands that we standardize these answers.
> I predict that we'll end up with these below(which I think match yours)
> but I fear that existing implementations differ from these a fair bit.
> - Only one name per type is allowed and used in the client hello SNI.
> - The session ID space covers all the sessions for the entire physical host
> including all the virtual hosts, so by itself, the session ID contains all
> the information necessary to determine which virtual host uses the session
> with that ID.  It is not necessary to consult the SNI host name to know
> which virtual host's session cache to examine to find the session ID.
> - The SNI extension is ignored if the session can be resumed based on the
> session ID, and no matching/checking is done to ensure that the SNI host
> name matches the name in the resumed session, when the session is resumed.
>> Also on previous note <snip> 'because they don't want to send the client
>> cert over the wire in the clear" <snip>
>> For what reason would you require a client cert or a host name or a host
>> certificate to be not treated as public information?  
> I don't know.  I work on NSS, an open source TLS library that is used in
> lots of applications and is discussed in an open mailing list and newsgroup
> (  One of the application developers who uses NSS
> has this issue, but I don't know why.  I'd guess it's the usual extreme
> security p\a\r\a\n\o\i\a\ precautions that have kept me employed. :)
>> Mick Gray
>> IBM