Re: [TLS] Wrapping up cached info

Nicolas Williams <> Mon, 17 May 2010 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CAB0C3A6A7C for <>; Mon, 17 May 2010 07:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.533
X-Spam-Status: No, score=-4.533 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vj0eL3UGcomX for <>; Mon, 17 May 2010 07:58:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 222383A6A77 for <>; Mon, 17 May 2010 07:58:26 -0700 (PDT)
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HEwBOK007440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 May 2010 14:58:13 GMT
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HBBv19015305; Mon, 17 May 2010 14:58:10 GMT
Received: from by with ESMTP id 270920411274108265; Mon, 17 May 2010 07:57:45 -0700
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 May 2010 07:57:44 -0700
Date: Mon, 17 May 2010 09:57:38 -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.0A090203.4BF15985.018D: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 14:58:31 -0000

On Mon, May 17, 2010 at 03:58:08PM +0200, Stefan Santesson wrote:
> I don't think the discussion has shown that the security assumptions are
> wrong, I.e. That any alteration of cached data in the sense that the server
> and the client are in disagreement of what the cached data is, will lead to
> a handshake failure.

If only "any alteration of cached data" in that sense were to lead to
handshake failure, then the protocol would be secure.  The fact that
we've not shown as much means that the protocol is suspect.

We should not be concerned with DoS attacks here because DoS attacks on
handshakes can't be defended against by TLS.  We're concerned with all
other active attacks, and these matter a lot more than DoS attacks.

I believe the only obvious and simple way to prevent such attacks and,
crucially, simplify the security analysis of this protocol, is to bind
the cached objects' data into the handshake, almost as if they'd not
been cached in the first place.