Re: [TLS] Wrapping up cached info

Nicolas Williams <> Mon, 17 May 2010 15:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6073728C18F for <>; Mon, 17 May 2010 08:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.541
X-Spam-Status: No, score=-4.541 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id StthnCy4lQ-8 for <>; Mon, 17 May 2010 08:38:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F009B28C198 for <>; Mon, 17 May 2010 08:35:08 -0700 (PDT)
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HFYuAO003448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 May 2010 15:34:58 GMT
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HBBv4l015305; Mon, 17 May 2010 15:34:55 GMT
Received: from by with ESMTP id 271081101274110488; Mon, 17 May 2010 08:34:48 -0700
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 May 2010 08:34:47 -0700
Date: Mon, 17 May 2010 10:34:40 -0500
From: Nicolas Williams <>
To: Stefan Santesson <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: []
X-CT-RefId: str=0001.0A090201.4BF16222.007B:SCFMA4539811,ss=1,fgs=0
Subject: Re: [TLS] Wrapping up cached info
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, 17 May 2010 15:38:08 -0000

On Mon, May 17, 2010 at 03:58:08PM +0200, Stefan Santesson wrote:
> I will not lead an effort to specify a variant of this protocol where the
> server provides the identifiers, either as any random identifier or in the
> form of a URI. If that is the desire of the WG, I will be happy to hand over
> editorship to anyone, assigned by the chairs, who wants to take over.

I don't care how the cached objects are identified.

It's not clear to me either how collisions in the cached object
checksums can be exploited, but it is clear that the security analysis
of the protocol is much simpler if you bind the cached objects into the
handshake.  Which is why I strongly encourage you to add such a binding
to the protocol.  I may well be alone in this, in which case I'd settle
for a requirement that one be able to disable caching in all

If the WG agrees to proceed without adding such a binding, then I'd also
like to see a detailed analysis of possible attacks and why they either
cannot happen or are of no value to the attacker.