Re: [TLS] Wrapping up cached info

"Kemp, David P." <DPKemp@missi.ncsc.mil> Wed, 19 May 2010 17:44 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
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 A42373A698E for <tls@core3.amsl.com>; Wed, 19 May 2010 10:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.261
X-Spam-Level:
X-Spam-Status: No, score=-4.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
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 raOiAmZXimBL for <tls@core3.amsl.com>; Wed, 19 May 2010 10:44:08 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id B395B3A697A for <tls@ietf.org>; Wed, 19 May 2010 10:44:06 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 19 May 2010 13:43:52 -0400
Message-ID: <201005191743.o4JHhsgS005542@stingray.missi.ncsc.mil>
In-Reply-To: <20100519165226.GG9605@oracle.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Wrapping up cached info
Thread-Index: Acr3c9ljpwexeKxgTLafwyMWDQZxvQAA3FUg
References: <C8178EA6.AE48%stefan@aaa-sec.com><C819B76D.AF2B%stefan@aaa-sec.com><AC1CFD94F59A264488DC2BEC3E890DE50A67CBEF@xmb-sjc-225.amer.cisco.com> <20100519165226.GG9605@oracle.com>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: <tls@ietf.org>
X-OriginalArrivalTime: 19 May 2010 17:45:09.0078 (UTC) FILETIME=[0636E760:01CAF77B]
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: Wed, 19 May 2010 17:44:09 -0000

This will work as long as there is high "cache reuse ratio", i.e.,
repeated handshakes with a server will not result in many cached objects
of any type.

If multiple handshakes with a server could cache different objects of a
given type, then the list in step 2 (client sends hash value of every
object it has collected) could get very large and a more traditional
cache miss approach would be needed.

The FNV collision discussion brought up cases where more than one cached
object could be valid.  The same cases should be considered in
estimating how long the list of cached objects might become.  If
collisions in a 64 bit checksum are a real concern, that list could
potentially be enormous.

Dave



-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
Nicolas Williams
Sent: Wednesday, May 19, 2010 12:52 PM
To: Joseph Salowey (jsalowey)
Cc: tls@ietf.org
Subject: Re: [TLS] Wrapping up cached info

On Wed, May 19, 2010 at 07:19:00AM -0700, Joseph Salowey (jsalowey)
wrote:
> To me this sounds like a good approach.  I have some questions on
> whether the hash chosen is dependent upon the cipher suite used below.

I agree, this works for me, provided the hashes are not truncated.
("This" == the client caches the choice of hash function and uses that
in its hello; if the hash function changes then the client cannot cache
that one time, but can cache subsequently.)

Nico
-- 
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls