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

Martin Rex <Martin.Rex@sap.com> Thu, 29 October 2009 23:26 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 5F0F33A6914 for <tls@core3.amsl.com>; Thu, 29 Oct 2009 16:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.107
X-Spam-Level:
X-Spam-Status: No, score=-6.107 tagged_above=-999 required=5 tests=[AWL=0.142, 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 fyskNWehXDaG for <tls@core3.amsl.com>; Thu, 29 Oct 2009 16:26:45 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 493343A6781 for <tls@ietf.org>; Thu, 29 Oct 2009 16:26:45 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n9TNQwWI013512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 00:26:58 +0100 (MET)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200910292326.n9TNQvVb016843@fs4113.wdf.sap.corp>
To: nelson@bolyard.me (Nelson B Bolyard)
Date: Fri, 30 Oct 2009 00:26:57 +0100 (MET)
In-Reply-To: <4AE8D30D.6020305@bolyard.me> from "Nelson B Bolyard" at Oct 28, 9 04:26:05 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: Alexei.Volkov@sun.com, tls@ietf.org
Subject: Re: [TLS] Questions about TLS Server Name Indication extension
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: Thu, 29 Oct 2009 23:26:46 -0000

Nelson B Bolyard wrote:
> 
> There's another issue that arises with both the SNI extension and a single
> session ID space for the entire physical server.  Which takes precedence?
> 
> 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,

That client is obviously broken.

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

If the server supports virtual hosting through SNI, it should
look up the session ID of the client only in the session cache
associated with the hostname A.

If a TLS session resume proposal with and SNI for B arrives,
there will be no cached session with that session ID in the
TLS session cache tied to credential for A, so it must result
in a full TLS handshake.

A server that has different credentials for A and B (and would
use them based on SNI is definitely broken if it agrees to a
proposed resume of a session originally established with A
in a ClientHello that carries an SNI for B, because the server
knows exactly that the server certificate that the client
has for this session is NOT the same certificate that the server
would send in a full handshake for B.  And similiar uncertainty
may apply to availability of a client certificate of even
an already cached client certificate.
 

-Martin