Re: [TLS] Wrapping up cached info

Nicolas Williams <Nicolas.Williams@oracle.com> Mon, 17 May 2010 17:29 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 C94823A6A47 for <tls@core3.amsl.com>; Mon, 17 May 2010 10:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.313
X-Spam-Level:
X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[AWL=1.285, BAYES_00=-2.599, 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 7qusy401hr9r for <tls@core3.amsl.com>; Mon, 17 May 2010 10:29:18 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 53FF23A6D08 for <tls@ietf.org>; Mon, 17 May 2010 10:28:26 -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 o4HHS8iC022884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 May 2010 17:28:11 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 o4H1T5tY015377; Mon, 17 May 2010 17:27:58 GMT
Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 247573521274117262; Mon, 17 May 2010 10:27:42 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 May 2010 10:27:41 -0700
Date: Mon, 17 May 2010 12:27:36 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Ben Laurie <benl@google.com>
Message-ID: <20100517172736.GA9429@oracle.com>
References: <C816DA05.66DF%uri@ll.mit.edu> <4BF168A3.40409@extendedsubset.com> <AC1CFD94F59A264488DC2BEC3E890DE50A67C326@xmb-sjc-225.amer.cisco.com> <4BF176BF.8020000@extendedsubset.com> <20100517170810.GY9429@oracle.com> <AANLkTimyy-PoErKMSAnpjT3bZGi_GN2t4h61XsZNtqY_@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <AANLkTimyy-PoErKMSAnpjT3bZGi_GN2t4h61XsZNtqY_@mail.gmail.com>
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.0A090202.4BF17CAB.0141:SCFMA922111,ss=1,fgs=0
Cc: tls@ietf.org
Subject: Re: [TLS] Wrapping up cached info
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 17:29:18 -0000

On Mon, May 17, 2010 at 06:17:37PM +0100, Ben Laurie wrote:
> On 17 May 2010 18:08, Nicolas Williams <Nicolas.Williams@oracle.com> wrote:
> > ...
> 
> This is, of course, equivalent to using the hashes as identifiers in the
> first place :-)

Almost!  Using the object ID hashes for this before we negotiate a hash
function creates a hash agility issue.  There's also the problem that
using secure hashes to ID the objects means using up more bits on the
wire, as Uri points out.  There's also the problem that if the client
and server disagree as to what hash to use to ID cacheable objects then
objects aren't cached at all.

If we do it the way I propose we: a) don't have to think about agility,
b) don't have to think too much about security analysis, c) never have
to change the hash function we use for naming objects (unless FNV proves
to be deeply unsatisfying), d) barely change the protocol (though the
changes to implementations are somewhat larger).

Nico
--