Re: [TLS] Multiple Session Caches and SNI (was Questions about TLS

Martin Rex <Martin.Rex@sap.com> Fri, 30 October 2009 18:52 UTC

Return-Path: <Martin.Rex@sap.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 13A563A6823 for <tls@core3.amsl.com>; Fri, 30 Oct 2009 11:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.178
X-Spam-Level:
X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 FeKNWBlj9v1P for <tls@core3.amsl.com>; Fri, 30 Oct 2009 11:52:28 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E2A8F3A6767 for <tls@ietf.org>; Fri, 30 Oct 2009 11:52:27 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n9UIqhDu008344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 19:52:43 +0100 (MET)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200910301852.n9UIqgev022554@fs4113.wdf.sap.corp>
To: mike-list@pobox.com (Michael D'Errico)
Date: Fri, 30 Oct 2009 19:52:42 +0100 (MET)
In-Reply-To: <4AEB1E13.4010002@pobox.com> from "Michael D'Errico" at Oct 30, 9 10:10:43 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Multiple Session Caches and SNI (was Questions about TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 30 Oct 2009 18:52:29 -0000

Michael D'Errico wrote:
> 
> The only thing you can count on when resuming a session is the session
> ID.  If you have more than one session cache, then you need to be able
> to determine solely from the session ID which session cache contains
> the session.  I do this by structuring the 32 bytes of the session ID
> into a 6-byte cache ID, a 10-byte counter, and 16 bytes of random noise.
> 
> The cache ID makes it easy to determine which cache to look in when
> trying to locate a session; the counter guarantees uniqueness of session
> IDs (the upper 5 bytes are initialized with the creation time); and the
> random component makes it unlikely for an attacker to guess a valid
> session ID randomly.
> 
> My implementation allows virtual hosts to have their own session cache
> or to share their cache with any number of other hosts.  Since session
> IDs are unique, the benefit to sharing is to share configuration
> parameters.  You can specify a limit to the total number of cached
> sessions and the expiration time on a per-cache basis.


It's perfectly sensible that TLS server composes the TLS session IDs
in a fashion that facilitates cache management and session lookup
(including guaranteed uniqueness when creating new session IDs,
obviating cache collision checks).

Keep in mind, that the security of the sessions do not come from
uniqueness and non-predictability of the session ID, however.
SSL session IDs travel in the clear in the client hello and
their purpose in life is to be re-used "replayed" frequently. :)


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.


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.

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.


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