Re: [TLS] New Cached info draft

Stefan Santesson <> Wed, 31 March 2010 23:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 922343A68E8 for <>; Wed, 31 Mar 2010 16:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.738
X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f1TzU6SW7z0X for <>; Wed, 31 Mar 2010 16:38:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 836733A6827 for <>; Wed, 31 Mar 2010 16:38:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 15A65381134 for <>; Thu, 1 Apr 2010 01:39:02 +0200 (CEST)
Received: (qmail 41457 invoked from network); 31 Mar 2010 23:38:52 -0000
Received: from (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <>; 31 Mar 2010 23:38:52 -0000
User-Agent: Microsoft-Entourage/
Date: Thu, 01 Apr 2010 01:38:50 +0100
From: Stefan Santesson <>
To: <>, Brian Smith <>
Message-ID: <>
Thread-Topic: [TLS] New Cached info draft
Thread-Index: AcrRK1CgdVrEfSfO+USKtQo8LIKEwQ==
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [TLS] New Cached info 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: Wed, 31 Mar 2010 23:38:23 -0000

On 10-03-31 8:47 PM, "Martin Rex" <> wrote:

>> I can see that it might be useful for the client to cache one value of each
>> cached information item that were obtained during initial (unauthenticated,
>> unencrypted) handshakes plus another set of values per client certificate
>> that were obtained during renegotiation following client authentication.
>> However, in that case, the server probably wouldn't want the client to leak
>> the hash of its second certificate in subsequent initial (unauthenticated,
>> unencrypted) handshakes. It seems something about this should be added to
>> the security considerations of the draft.
> Interesting, I hadn't thought of this aspect.  I think that the
> caching extension (update of client cache, proposal of cached values)
> should apply to all full handshakes, which includes TLS renegotiations,
> this will likely make hashes from data exchanged on a confidential
> rengotiation handshake visible on new in-the-clear handshakes.
>> If there are other cases where it seems useful to have the client send
>> multiple hashes for the same information item, then those cases should also
>> be discussed before publication so that the security properties of that
>> those kind of usages can be analyzed. For example, I think it is a big
>> privacy problem to send a digest of a value obtained from one server to
>> another server.
> I mainly see a privacy problem for the client, similar to HTTP-Referers:
> or the browser cache.  Maybe a "Cache considerations" sections would
> be appropriate.

I'm still not sure what the threat is.

The client only gives away digest values. In order to know what data these
hash values represent, the "attacker" reasonably needs access to the cached

I can't think of anything useful or serious the attacker can do with this.