Re: [TLS] Justification

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24D693A69FF for <>; Mon, 17 May 2010 08:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UmrtCRH9QkZF for <>; Mon, 17 May 2010 08:26:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6FB1D28C11B for <>; Mon, 17 May 2010 08:20:53 -0700 (PDT)
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HFKZCn025781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 May 2010 15:20:37 GMT
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HBuH0Z008418; Mon, 17 May 2010 15:20:34 GMT
Received: from by with ESMTP id 247115761274109625; Mon, 17 May 2010 08:20:25 -0700
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 May 2010 08:20:18 -0700
Date: Mon, 17 May 2010 10:20:12 -0500
From: Nicolas Williams <>
To: Dean Anderson <>
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.0A090205.4BF15EC6.00D7:SCFMA922111,ss=1,fgs=0
Cc: Simon Josefsson <>, "Kemp, David P." <>,
Subject: Re: [TLS] Justification
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:26:10 -0000

On Thu, May 13, 2010 at 08:23:33PM -0400, Dean Anderson wrote:
> I rather thought the objective of caching was to have faster startup by
> having to move less data around, particularly when its already been
> moved before. But I haven't been following the extension too closely. 
> I am only concerned when I see suggestions that 'http be used to get TLS
> data. I'm not sure whether to those were serious or tongue-in-cheek.  

First, HTTP already is used to get what you might call TLS data, such as

Second, I only want to assign URIs to cacheable TLS data, not so much
make it fetchable via URIs.  This is a variant of my earlier suggestion
of server-side object IDs; this variant can result in efficient caching
of the same objects used by many servers (e.g., certification chains).

> HTTP secured by and depends on TLS, so you can't draw on HTTP to solve
> HTTP-TLS-HTTP without looping or creating security holes.

You clearly didn't read what I'd written.  The key problem with this
extension is that the cached objects aren't bound into the handshake.
IMO regardless of how the cached object IDs are obtained, whether by
SHA-1 hashing, FNV-1a hashing, server-assigned IDs, or URIs, the object
data must be bound into the handshake.  Given such binding then it
doesn't matter how you retrieve these objects (which are, for the most
part, public data).