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

Nelson B Bolyard <nelson@bolyard.me> Wed, 28 October 2009 23:26 UTC

Return-Path: <nelson@bolyard.me>
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 67F9F3A68C7 for <tls@core3.amsl.com>; Wed, 28 Oct 2009 16:26:07 -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 PaRuRZ6e3bjC for <tls@core3.amsl.com>; Wed, 28 Oct 2009 16:26:06 -0700 (PDT)
Received: from smtpauth18.prod.mesa1.secureserver.net (smtpauth18.prod.mesa1.secureserver.net [64.202.165.31]) by core3.amsl.com (Postfix) with SMTP id 8454E3A67FC for <tls@ietf.org>; Wed, 28 Oct 2009 16:26:06 -0700 (PDT)
Received: (qmail 28374 invoked from network); 28 Oct 2009 23:26:15 -0000
Received: from unknown (67.188.69.99) by smtpauth18.prod.mesa1.secureserver.net (64.202.165.31) with ESMTP; 28 Oct 2009 23:26:15 -0000
Message-ID: <4AE8D30D.6020305@bolyard.me>
Date: Wed, 28 Oct 2009 16:26:05 -0700
From: Nelson B Bolyard <nelson@bolyard.me>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: tls@ietf.org
References: <E1N32Q4-00072H-J3@wintermute01.cs.auckland.ac.nz> <4AE880CA.3060902@bolyard.me> <e8c553a60910281230t56e5ebf1w861174cd6bc10ebb@mail.gmail.com>
In-Reply-To: <e8c553a60910281230t56e5ebf1w861174cd6bc10ebb@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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: Wed, 28 Oct 2009 23:26:07 -0000

On 2009-10-28 12:30 PDT, Wan-Teh Chang wrote:
> On Wed, Oct 28, 2009 at 10:35 AM, Nelson B Bolyard <nelson@bolyard.me> wrote:
>> 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.
> 
> When attempting to resume a TLS session, the client hello must
> bear an SNI extension for another reason: it's not guaranteed that
> the server will accept the request to resume the session.  This issue
> is discussed in Section 2.3 of the TLS extensions RFC 3546.  (The
> RFC uses SHOULD instead of MUST.)
> 
>> 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.

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,

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.

RFC 5246 seems to suggest choice A.  It says:

   Most current TLS extensions are relevant only
   when a session is initiated: when an older session is resumed, the
   server does not process these extensions in Client Hello, and does
   not include them in Server Hello.

But I tend to lean towards choice B myself.

What do other SNI server implementations do in this case?