IETF Logo Mail Archive

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

Wan-Teh Chang <wtc@google.com> Wed, 28 October 2009 19:30 UTC

Return-Path: <wtc@google.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 8CAEE3A689D for <tls@core3.amsl.com>; Wed, 28 Oct 2009 12:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 jxjD9zIkFDCI for <tls@core3.amsl.com>; Wed, 28 Oct 2009 12:30:16 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id C431B3A6836 for <tls@ietf.org>; Wed, 28 Oct 2009 12:30:15 -0700 (PDT)
Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id n9SJUUGd001284 for <tls@ietf.org>; Wed, 28 Oct 2009 12:30:30 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1256758231; bh=uPmBVX8zbC/fumf8LR+Ww1WG5l4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=nLOer3RRgyMUexAuy4F6pSjSXG2n0xIwtd9aWFpvfeWlf1OV8i32gGYUSeMJv1iw4 9wRWlQ/zPG3GEkz8q9a7g==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=WvlxBGYo3mzHpG3bB8t6hBh/twleE5og7wE1SBzQSyjv/hxF9AwNBVhNoViLIsVIe 60dqwphUIA/OvM67eBNWA==
Received: from pxi2 (pxi2.prod.google.com [10.243.27.2]) by wpaz33.hot.corp.google.com with ESMTP id n9SJURmf028447 for <tls@ietf.org>; Wed, 28 Oct 2009 12:30:28 -0700
Received: by pxi2 with SMTP id 2so790612pxi.11 for <tls@ietf.org>; Wed, 28 Oct 2009 12:30:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.1.24 with SMTP id 24mr1412771wfa.73.1256758227490; Wed, 28 Oct 2009 12:30:27 -0700 (PDT)
In-Reply-To: <4AE880CA.3060902@bolyard.me>
References: <E1N32Q4-00072H-J3@wintermute01.cs.auckland.ac.nz> <4AE880CA.3060902@bolyard.me>
Date: Wed, 28 Oct 2009 12:30:27 -0700
Message-ID: <e8c553a60910281230t56e5ebf1w861174cd6bc10ebb@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: Nelson B Bolyard <nelson@bolyard.me>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
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
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 19:30:19 -0000

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.

If a client certificate is used in the session, it seems that the
session should only be associated with the virtual server that
authenticated the client certificate, as opposed to the entire
physical server covering all the virtual servers.  I guess there
are multiple ways to accomplish that.

Wan-Teh

v2.23.0 | Report a Bug | By Email