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

Brian Smith <> Fri, 19 February 2010 17:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C162728C25A for <>; Fri, 19 Feb 2010 09:03:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DlMVFMnAQIIp for <>; Fri, 19 Feb 2010 09:03:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E8B3128C2AE for <>; Fri, 19 Feb 2010 09:03:33 -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 7FF7C22E1F3; Fri, 19 Feb 2010 12:05:19 -0500 (EST)
Message-ID: <>
Date: Fri, 19 Feb 2010 11:05:21 -0600
From: Brian Smith <>
User-Agent: Postbox 1.1.1 (Windows/20100208)
MIME-Version: 1.0
To: "Kemp, David P." <>
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090402030706020107020006"
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:03:35 -0000

Kemp, David P. wrote:
> Note that the key concept described in _secure_hashing.html_ is “secure”:
> /Federal agencies should stop using SHA-1 for digital signatures, 
> digital time stamping and other applications that require collision 
> resistance as soon as practical, and must use the SHA-2 family of hash 
> functions for these applications after 2010./
> / /
> When a hash algorithm is used for non-security purposes, such as 
> database bucketing ( or cache 
> object selection, the NIST guidance does not apply.
Yes, I read that sentence too. And, I agree with your very common-sense 
interpretation of things. But, while the sentence you quote has the 
qualifier "that require collision resistance," the rest of the 
recommendations against SHA-1 don't have that qualifier, so I am not 
totally convinced. And, I am definitely not convinced that all 
users/customers will be convinced, so I would rather be safe than sorry.

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;

In a server hello: If CachedObject.token is empty, then the client must 
use its cached value for the given information type. The corresponding 
fields in the server hello (e.g. Certificate.certificate_list or 
CertificateRequest.certificate_authorities) MUST be empty. If 
CachedObject.token is not empty, then the server will send a new value, 
and that new value can be identified by the client in subsequent client 
hellos using the given token; an empty value (e.g. an empty 
Certificate.certificate_authorities) must not be interpreted as an 
indication to use a previously-cached value. For a given value, a server 
should return the same token string to every client, so that the token 
isn't used as a tracking cookie that could be used to distinguish 
distinct clients. The server must ensure that the same token is never 
used to identify different values (that is, every token must map to at 
most one value). Since the goal of this extension is to reduce the 
number of bytes transmitted, the token should be short. It is strongly 
recommended that the server use a secure hash algorithm (e.g. SHA-2) of 
the value as the token.

In a client hello: CachedObject.token must not be empty, and it must 
contain a token previously retrieved from the same server (either in a 
previous TLS handshake, or out of band).