Re: [TLS] Multiple Session Caches and SNI

Michael D'Errico <> Sat, 31 October 2009 00:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB4B53A6935 for <>; Fri, 30 Oct 2009 17:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GekFJI-VIVKZ for <>; Fri, 30 Oct 2009 17:38:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9F9BD3A672E for <>; Fri, 30 Oct 2009 17:38:30 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 9CA256D0B6 for <>; Fri, 30 Oct 2009 20:38:47 -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=bcIE1LdGB66v jRQcMiuAtyci5uA=; b=Oc2qm1V+1kfHV+rCVHMYB2zU9Y2SREENsnaiplugcaxj dSNdCjuZTivJgcFk5ATMs2MrpL1pTogzeb+Ayombk+u77XQM5y6DUDq+3oeqcNNJ PfLm7xHuPHJHU+2FyaXpbIku6vuR+DOYe0ZESVGPpig+1DggOukQDbDlDEwq1Vo=
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=Om64Li qOk8d2gcn7LDipHvrHwVPhsSLx2XCcLa5+G6pQwCiEdfBBZm0JAcX3NIAzVowFSd 1h8Swqnh5jEBqozmTlNBIMQHoRtumIlZV8JDlIqY4+0e+DCkocGR7UNLwywWIBrQ 6ouVm2E7+EEHjdwmpOowXTRjojuzfklRBp6YE=
Received: from a-pb-sasl-quonix. (unknown []) by (Postfix) with ESMTP id 98E1A6D0B5 for <>; Fri, 30 Oct 2009 20:38:47 -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 2B05B6D0B4 for <>; Fri, 30 Oct 2009 20:38:47 -0400 (EDT)
Message-ID: <>
Date: Fri, 30 Oct 2009 17:40:19 -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: C06F9642-C5B5-11DE-ABB2-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: Sat, 31 Oct 2009 00:38:32 -0000

>> 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.
> That appears to strict to me.  I would make the server delete
> a session from his cache when an attempted resume results in a failure.
> I can not currently think of an error (i.e. fatal alert) after a
> mutual successful finished message verification that should cause
> the server to flush the affected ssl session from his session cache.

The main one is a BAD_RECORD_MAC alert if decryption fails, padding
is wrong, the MACs don't match.  The record version could be wrong;
the record could be greater than 2^14 bytes.  None of these things
should happen under normal circumstances, so you have to assume an
attack is underway.

>>> 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.
> Correct, but you should not read it backwards.
> If the server agrees to resume (for whatever reason), the other
> accompanying information in the ClientHello should NOT be used to
> modify that cached session.
> Does rfc-4366 say anywhere that the server _must_not_ involve the
> parameters and extensions present in a ClientHello in his decision
> to resume or not resume a cached SSL session when the client
> includes a session id in the ClientHello handshake message?

Aside from what I quoted, I don't believe so.  The server can decide
not to resume a session for whatever reason it wants.  In fact there
is no requirement to support session caching at all.  What the text
means is that IF the server agrees to resume the session, the resumed
session will have the same features as the original according to the
extensions in the original handshake, regardless of the extensions in
the ClientHello for the resumed session.