Re: [TLS] Questions about TLS Server Name Indication extension

Michael D'Errico <mike-list@pobox.com> Wed, 28 October 2009 23:17 UTC

Return-Path: <mike-list@pobox.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FEDA28C0D0 for <tls@core3.amsl.com>; Wed, 28 Oct 2009 16:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ8QFZiYFUJh for <tls@core3.amsl.com>; Wed, 28 Oct 2009 16:17:56 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 23E913A677C for <tls@ietf.org>; Wed, 28 Oct 2009 16:17:55 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 224A48922B for <tls@ietf.org>; Wed, 28 Oct 2009 19:18:11 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=oEeEOVlp2eS0 Ay8udhJtNesj0Qo=; b=SkvOlYIyQwPjT7FGIcNDCH5kYGLeJqOcZuOYLVCVh7Vs nlzW0rrjhE/AC8zyoS1rNCVWleJHlpT7j++h81jfEh0do8jUWFEq8BXk2w1xhP9k xzeXYHwCY6YhcCwUXGrykG+4IzzjwriGDip+2+ytHZgjw0SMJpTmlxmXWpkgCd0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=iIuRjl Ahjwbm+wXVc7TrKihA2gN6NcNdJ35TgoTFhgzwxHK2gzZk5BkgRKcGPDcj5/M5k/ JIrYFhWaVNatnJmyKg2fiTS9p8X2Ik20sAalWPdOYx9WoJfHDjtUvuFEjhSu5OoW ixZq7bpgPFXfQw2dc7yI2wnZseVvxPOSh4LFg=
Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 1C3F58922A for <tls@ietf.org>; Wed, 28 Oct 2009 19:18:11 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 72D1189218 for <tls@ietf.org>; Wed, 28 Oct 2009 19:17:59 -0400 (EDT)
Message-ID: <4AE8D177.3060805@pobox.com>
Date: Wed, 28 Oct 2009 16:19:19 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: tls@ietf.org
References: <4AE7BC74.9010806@bolyard.me>
In-Reply-To: <4AE7BC74.9010806@bolyard.me>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 28CF9376-C418-11DE-9F5C-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com
Subject: Re: [TLS] Questions about TLS Server Name Indication extension
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2009 23:17:57 -0000

In my TLS implementation, I have created an object called a ServerIdentity
which is more general than a domain name.  A TLS server can be set up
with any number of server identites, each of which can have any number of
domain names and certificate chains, and you can also specify a few server
options on a per-identity basis.

When the Server Name Indication extension is received, the server goes
through the list of domain names in order and searches for the ServerIdentity
object containing the domain name.  The first match is chosen and the
handshake continues using the most appropriate certificate chain and also
the options set for that identity.

If none of the SNI names match, the server checks to see if a default
ServerIdentity has been configured.  If it has, the default identity is
used, but an UnrecognizedName alert is sent to the client (level = warning).
If no default identity has been configured, then a fatal UnrecognizedName
alert is sent and the connection fails.

My test server has two identities set up:

    Mike's Toolbox Network
    www.mikestoolbox.net + default
    RSA/SHA-1 signed RSA certificate chain
    RSA/SHA-1 signed DSA certificate chain (only works with TLS 1.2)
    RSA/SHA-256 signed RSA certificate chain
    RequestClientCertificate
    LoadDefaultRootCertificates
    Use1024BitDHParameters
    CacheSessions
    IssueSessionTickets

    Mike's Toolbox Charity
    www.mikestoolbox.org
    RSA/SHA-1 signed RSA certificate chain
    RSA/SHA-256 signed RSA certificate chain
    Use1536BitDHParameters
    CacheSessions
    IssueSessionTickets

When you connect to the test server, the information returned includes the
server identity that was negotiated.

Mike



Nelson B Bolyard wrote:
> A few years ago, I implemented the SNI extension in a client-only TLS
> library and it was really simple because I only ever sent one host name
> to the server.  Now I'm implementing the server side of SNI and I realize
> that the RFC appears to allow clients to do much more complex things than
> my client ever did.  So, I have some questions seeking clarification about
> the definition of SNI.  I hope someone here can help me by answering some
> of these questions.
> 
> Q1)  A client hello's SNI extension is defined such that it may contain
> multiple names.  Perhaps the intent was to allow the same server to be
> named in multiple different name spaces (DNS and others), but I saw nothing
> in RFC 4366 that precludes the client from naming multiple different hosts
> in a single ServerNameList.  If a client names multiple host names in a
> single client hello SNI extension (let's call them A.foo.com, B.foo.com and
> C.foo.com) how does the client learn which one of those has been chosen by
> the server?  RFC 4366 requires the "extension_data" field of the SNI
> extension in the server hello to be empty.  The server may respond with a
> "wildcard" certificate ("*.foo.com"), or with a certificate with multiple
> Subject Alternative Names that include more than one of the names given by
> the client.  In that case, how does the client know which FQDN is the one
> that the physical server has chosen/identified?
> 
> I can think of lots of possible answers here, including
> 
> a) It is an error to include multiple names in the same name space, e.g.
> multiple DNS names. (but the RFC doesn't say that.)
> 
> b) If multiple names are included, they must be logically synonymous, all
> alternative names for the same host.  (What if they're not?)
> 
> Q2) if multiple non-synonymous names are included, is the server free to
> pick any one that it wants?
> 
> Q3) Consider the "renegotiation" case, where a client and server negotiate
> an initial SSL handshake ("in the clear") and then negotiate a second
> handshake over the encrypted channel established by the first handshake.
> Are there any special requirements or prohibitions on the use and contents
> of the client hello's SNI extension in the renegotiation case?
> 
> Q3a) Is SNI permitted in that case?
> Q3b) Is it required to match the SNI of the original handshake, if any?
> Q3c) If it contains multiple non-synonymous host names, is the server
> allowed to choose a different one than the one chosen in the first
> handshake?
> 
> The next questions have to do with the "resumption" or "restart" of a TLS
> session that has been previously established using an SNI extension that
> named one or more virtual hosts in a connection to a physical server on
> an IP address and port.
> 
> Q4) In that context, is the scope of a TLS session ID that of the physical
> server, or that of a virtual server?  When attempting to restart a TLS
> session on a new connection, does the TLS session ID in the client hello
> uniquely identify the virtual host and its session to the physical server,
> even in the absence of an SNI extension?  Or is it possible that each of
> the virtual servers within the physical host may have used that same
> session ID, in which case it would be necessary for the client to supply the
> virtual host's FQDN in an SNI extension to uniquely identify the session?
> 
> Q5) When an SNI extension was used to establish a TLS session, it is
> required that an SNI extension bearing the same host name be used in the
> client hello that attempts to "restart" or "resume" the session on a new
> connection?
> 
> (Obviously Q3, Q4 and Q5 overlap.)
> 
> 
> I eagerly await your answers and comments.
> 
> /Nelson Bolyard
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>