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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 29 October 2009 05:58 UTC

Return-Path: <pgut001@wintermute01.cs.auckland.ac.nz>
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 B82153A67AE for <tls@core3.amsl.com>; Wed, 28 Oct 2009 22:58:06 -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 TXd+uWaQOl8H for <tls@core3.amsl.com>; Wed, 28 Oct 2009 22:58:06 -0700 (PDT)
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id BE15C3A66B4 for <tls@ietf.org>; Wed, 28 Oct 2009 22:58:04 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A847D9F240; Thu, 29 Oct 2009 18:58:11 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyyQcc-adzbL; Thu, 29 Oct 2009 18:58:11 +1300 (NZDT)
Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E655C9F178; Thu, 29 Oct 2009 18:58:10 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1N3O1S-0001OS-IY; Thu, 29 Oct 2009 18:58:10 +1300
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1N3O1S-00053d-Kt; Thu, 29 Oct 2009 18:58:10 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: nelson@bolyard.me, tls@ietf.org
In-Reply-To: <4AE880CA.3060902@bolyard.me>
Message-Id: <E1N3O1S-00053d-Kt@wintermute01.cs.auckland.ac.nz>
Sender: pgut001 <pgut001@wintermute01.cs.auckland.ac.nz>
Date: Thu, 29 Oct 2009 18:58:10 +1300
Cc: Alexei.Volkov@Sun.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: Thu, 29 Oct 2009 05:58:06 -0000

Nelson B Bolyard <nelson@bolyard.me> writes:

>In the context of a physical server acting as multiple virtual server, is the
>space of session IDs coming from that server a single space that encompasses
>all the sessions for all the virtual servers served by that physical server?
>Or does each virtual server have its own separate space?
>
>If each virtual server has its own separate session ID space, then when
>attempting to "resume" or "restart" a TLS session, the client hello MUST bear
>an SNI extension to inform the physical server which virtual server's session
>ID space contains the given session ID, and each virtual server potentially
>has its own separate session store/cache.
>
>OTOH, if there is a single session ID space for the entire physical server
>covering all the virtual servers, then each cached session must record and
>identify the virtual server with which it is associated.

Ah, I see what you mean now.  Well in general I don't think it's going to be
an issue, the session ID is a 32-byte blob so it's up to the server what it
puts in there, it can include a virtual server ID, cache ID, whatever it wants
in any format it requires.  In other words if the server wants to encode
configuration- or server architecture-specific details in the session ID then
the form and type is up to the server, you don't need an explicit SNI for
this, particularly since the free-form blob accomodates much more than just
the virtual server : cache ID pair that the SNI + session ID handles.

Peter.