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

Michael Gray <mickgray@au1.ibm.com> Fri, 30 October 2009 19:32 UTC

Return-Path: <mickgray@au1.ibm.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 85C8C3A686B for <tls@core3.amsl.com>; Fri, 30 Oct 2009 12:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 9DlN4OCAX9a5 for <tls@core3.amsl.com>; Fri, 30 Oct 2009 12:32:22 -0700 (PDT)
Received: from e23smtp09.au.ibm.com (e23smtp09.au.ibm.com [202.81.31.142]) by core3.amsl.com (Postfix) with ESMTP id 887ED3A67A3 for <tls@ietf.org>; Fri, 30 Oct 2009 12:32:22 -0700 (PDT)
Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp09.au.ibm.com (8.14.3/8.13.1) with ESMTP id n9UJWcY4027779 for <tls@ietf.org>; Sat, 31 Oct 2009 06:32:38 +1100
Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9UJWbmQ1495272 for <tls@ietf.org>; Sat, 31 Oct 2009 06:32:37 +1100
Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9UJWbTS003466 for <tls@ietf.org>; Sat, 31 Oct 2009 06:32:37 +1100
Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9UJWbea003463; Sat, 31 Oct 2009 06:32:37 +1100
In-Reply-To: <4AEB126F.2090105@pobox.com>
To: "Michael D'Errico" <mike-list@pobox.com>
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: <OF5168C41E.ACA888DA-ON4A25765F.0068520A-4A25765F.006B55C0@au1.ibm.com>
From: Michael Gray <mickgray@au1.ibm.com>
Date: Sat, 31 Oct 2009 05:32:23 +1000
X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 31/10/2009 06:39:06
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Cc: tls@ietf.org
Subject: Re: [TLS] Multiple domain names in SNI (was 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: Fri, 30 Oct 2009 19:32:24 -0000

"Michael D'Errico" <mike-list@pobox.com> wrote:

> Here's a possible reason for a client to include multiple domain
> names in the SNI.  Suppose a user enters "foo.edu" into their
> browser.  The browser may decide to send the two names "foo.edu"
> and also "www.foo.edu" 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.

That is an interesting use case scenario.  Have you actually observed a
browser doing this?  I have not so far.  What sort of risk is there for the
Client if the browser starts doing this sort of thing?  On the other hand I
recommend to our consuming products to have the flexibility at the Server
side i.e. the Server is configured with multiple Server Names that point to
a common certificate which supports multiple DNS names.  For example say a
Server is hosting 123.com, abc.com and xyz.com, then the TLS Server can be
configured with:

abc.com > abc.com_certificate
www.abc.com > abc.com_certificate
123.com > 123.com_certificate
www.123.com > 123.com_certificate
...

You can imagine a number of variations on the above when you see some
Server Certificates with a large number of SAN DNS names.

The TLS Server then selects the correct certificate based on the TLS Client
SNI request.  The Application Server itself then asks the TLS Server what
certificate was used to establish the connection so that the Application
Server can select the correct data base etc etc.


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

If there is consensus on this and no security risk then we would implement
it as an option as I do not see that the RFC prevents this.

Mick Gray
IBM

> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls