Re: [TLS] Multiple Session Caches and SNI

Michael D'Errico <> Fri, 30 October 2009 19:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0520C3A6842 for <>; Fri, 30 Oct 2009 12:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E16OdjEZZtsz for <>; Fri, 30 Oct 2009 12:24:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D7F1D3A67A3 for <>; Fri, 30 Oct 2009 12:24:28 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id ACA176D412 for <>; Fri, 30 Oct 2009 15:24:45 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=4cZilZth/RZ8 xh1HfVC9O4ungQs=; b=VX+dzoQzhVwZ0sQiRj8w5Ffbr3KcAVHj+WUgpCQKU5PY e9b4cLtKLr6MFcTIKv0bmg57gUxNBazURNnG2krSub9dxmfXuYkJQEQF3n6SxkH7 JaHls0t9+ZVH3T9OwfxyJ7AtiJwGu/pUaN5hvVZDbuSJ9qsNl2N+To9Y2XiV+po=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=H7+Flp 1JjECeZ7FEhB8mEWv0L8Q5GsJSS8BP8ZqQK9gqfxyEVJSG0Vk7abVOFO3Gv/U9Pl oHY7In7qA9kWaIaDjRCRO2l89Aj3q7zfgp5C0NfJB/Q71dMyQfQf9qBlz0DFk4B5 ddkzmwWqk26m/700/nnIpHUOAazWnHEzcszwQ=
Received: from a-pb-sasl-quonix. (unknown []) by (Postfix) with ESMTP id A95276D411 for <>; Fri, 30 Oct 2009 15:24:45 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 350006D410 for <>; Fri, 30 Oct 2009 15:24:45 -0400 (EDT)
Message-ID: <>
Date: Fri, 30 Oct 2009 12:26:15 -0700
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: E1C4645C-C589-11DE-9E98-1B12EE7EF46B-38729857!
Subject: Re: [TLS] Multiple Session Caches and SNI
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Oct 2009 19:24:30 -0000

> In addition to cache management aspects, the TLS server should keep
> robustness in mind.  e.g. robustness against TLS clients with
> a broken client-side TLS session cache management that will
> recklessly propose a TLS session resume for a session (ID) originally
> established with Mars to just about every earthling they're asked
> to connect to later on.

Section 7.2.2 of RFC 5246 concerning Error Alerts handles this.  If
a connection terminates with a fatal alert, the session associated
with that connection MUST NOT be resumed.  So perhaps a server will
try to resume the session once, but it will delete it from its cache
when the handshake fails.  Other servers that don't recognize the
session ID will perform full handshakes.

> And before a TLS server checks for existence of a TLS session,
> whose session ID is proposed in a ClientHello, it should determine
> wheter it would be willing to establish a new session through
> a full handshake based on the other information in the ClientHello
> and under what conditions it would do so.

I do it the other way around -- after retrieving the session, checks
are made to make sure the cipher suite and compression algorithm are
listed in the ClientHello.  This is mandatory according to section  The only other check I currently have is for the age of the
session to make sure it is fresh enough.

> If the TLS server finds a TLS session with the proposed session ID
> in his cache, it should then use the results from the previous
> determination of the ClientHello parameters whether it is OK to
> attempt to resume the cached session, or whether it is advised
> to perform a full SSL handshake, because of a significant mismatch
> of the newly determine session characteristics from those
> of the cachend session identified by the client-proposed Session ID.

RFC 4366 states:

    -  If, on the other hand, the older session is resumed, then the
       server MUST ignore the extensions and send a server hello
       containing none of the extension types.  In this case, the
       functionality of these extensions negotiated during the original
       session initiation is applied to the resumed session.


> This is a simple and straightforward robustness principle leading
> to consistent behaviour, that will save implementors and consumers
> of the technology a lot of time and headaches.
> -Martin