Re: [TLS] Justification

Nicolas Williams <Nicolas.Williams@oracle.com> Mon, 17 May 2010 15:26 UTC

Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D693A69FF for <tls@core3.amsl.com>; Mon, 17 May 2010 08:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmrtCRH9QkZF for <tls@core3.amsl.com>; Mon, 17 May 2010 08:26:08 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6FB1D28C11B for <tls@ietf.org>; Mon, 17 May 2010 08:20:53 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (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 acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HBuH0Z008418; Mon, 17 May 2010 15:20:34 GMT
Received: from abhmt019.oracle.com by acsmt353.oracle.com with ESMTP id 247115761274109625; Mon, 17 May 2010 08:20:25 -0700
Received: from oracle.com (/129.153.128.104) 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 <Nicolas.Williams@oracle.com>
To: Dean Anderson <dean@av8.com>
Message-ID: <20100517152011.GR9429@oracle.com>
References: <4BEAC145.60607@pobox.com> <Pine.LNX.4.44.1005132018460.13071-100000@citation2.av8.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.1005132018460.13071-100000@citation2.av8.net>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090205.4BF15EC6.00D7:SCFMA922111,ss=1,fgs=0
Cc: Simon Josefsson <simon@josefsson.org>, "Kemp, David P." <DPKemp@missi.ncsc.mil>, tls@ietf.org
Subject: Re: [TLS] Justification
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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
CRLs.

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).

Nico
--