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

Martin Rex <Martin.Rex@sap.com> Fri, 30 October 2009 19:14 UTC

Return-Path: <Martin.Rex@sap.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 108AB28B23E for <tls@core3.amsl.com>; Fri, 30 Oct 2009 12:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.188
X-Spam-Level:
X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 rFU9xuHOBDei for <tls@core3.amsl.com>; Fri, 30 Oct 2009 12:14:18 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 021003A6AB1 for <tls@ietf.org>; Fri, 30 Oct 2009 12:14:17 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n9UJEXL8002770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 20:14:34 +0100 (MET)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200910301914.n9UJEXD9023612@fs4113.wdf.sap.corp>
To: mike-list@pobox.com (Michael D'Errico)
Date: Fri, 30 Oct 2009 20:14:33 +0100 (MET)
In-Reply-To: <4AEB32FC.8030100@pobox.com> from "Michael D'Errico" at Oct 30, 9 11:39:56 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Multiple domain names in SNI (was Questions about TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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:14:19 -0000

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