Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft

Brian Smith <> Mon, 01 March 2010 14:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E6D2428C0F1 for <>; Mon, 1 Mar 2010 06:29:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wI9ikEHfGdHV for <>; Mon, 1 Mar 2010 06:29:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2C3BD3A8781 for <>; Mon, 1 Mar 2010 06:29:25 -0800 (PST)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 0B007509DD; Mon, 1 Mar 2010 09:29:15 -0500 (EST)
Message-ID: <>
Date: Mon, 01 Mar 2010 08:29:12 -0600
From: Brian Smith <>
User-Agent: Postbox 1.1.1 (Windows/20100208)
MIME-Version: 1.0
To: Stefan Santesson <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson <>,
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
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: Mon, 01 Mar 2010 14:29:26 -0000

Stefan Santesson wrote:
> It seems like an unnecessary complexity.
> The original approach have two functions
> 1) Client informs the server what information it has cached
> 2) Server accepts caching and replaces the data with the hash provided by
> the client
> In the alternative approach this is expanded to:
> 1) The client tells server that it wants to cache data
> 2) The server provides hashes/identifiers of info the client may cache
> 3) The client signals that it has cached info with identifiers provided by
> the server
> 4) The server replaces cached data
> I see no reason to make the protocol any more complex than it need to be.
In the alternative approach, there is no need to pass multiple hashes of 
the same item back/forth, so the syntax becomes simpler. Also, the 
client and server do not have to agree on a hash algorithm at all, which 
is a big simplification. The client doesn't have to calculate anything, 
which is a further simplification.

Many clients won't want to cache this information unless the server says 
that it supports the extension. That is why Adam Langley and others have 
asked for a ServerHello extension that indicates the items for which the 
server supports caching. It is very easy for the server to just stuff 
the identifiers inside that extension.