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

Martin Rex <> Fri, 19 February 2010 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 607A83A7FB7 for <>; Fri, 19 Feb 2010 09:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.218
X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2us9WjoEZk6E for <>; Fri, 19 Feb 2010 09:43:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6297F3A7D70 for <>; Fri, 19 Feb 2010 09:43:44 -0800 (PST)
Received: from by (26) with ESMTP id o1JHjRBL029550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Feb 2010 18:45:27 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
To: (Brian Smith)
Date: Fri, 19 Feb 2010 18:45:26 +0100 (MET)
In-Reply-To: <> from "Brian Smith" at Feb 19, 10 11:05:21 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
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: Fri, 19 Feb 2010 17:43:45 -0000

Brian Smith wrote:
> Perhaps this all can be avoided by simply not having the client 
> calculate hashes at all for . For example, would this work?:
> struct {
>      CachedInformationType type;
>      opaque token<0..255>;
> } CachedObject;

I've been advocating the use of a hash value over the real data
so that the handshake will do the right thing automatically if
the data cached by the client and the data the server is going
to return no longer match: the server is going to send the new
data in full, and the client can update his cache.

You definitely do not want a handshake failure (which always
requires application involvement to recover from and a 
new connection) if the data cached by the client is out of
sync with what the server wants to return.

The client needs to be able to distinguish omitted handshake
data (which he has cached) from new real data, and the
server should not be forced to precompute all handshake
messages when composing the server hello handshake message
in order to confirm matches to the data that the client
has indicated to have cached.