Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Tue, 02 March 2010 17:30 UTC

Return-Path: <jsalowey@cisco.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 0B23928C1F0 for <tls@core3.amsl.com>; Tue, 2 Mar 2010 09:30:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 ilJP+-pe8y71 for <tls@core3.amsl.com>; Tue, 2 Mar 2010 09:30:50 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5245328C1EA for <tls@ietf.org>; Tue, 2 Mar 2010 09:30:50 -0800 (PST)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAJvajEurRN+K/2dsb2JhbACDBZcdYHOnC4gckDaBNIEbgUJqBIMX
X-IronPort-AV: E=Sophos;i="4.49,568,1262563200"; d="scan'208";a="94661907"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2010 17:30:39 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o22HUdsf018777; Tue, 2 Mar 2010 17:30:39 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 09:30:39 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Tue, 2 Mar 2010 09:30:38 -0800
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE509BD3594@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <4B8BCF38.5030104@briansmith.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
Thread-Index: Acq5S5tynLFDszVpTL69lIbGJgQdRgA4iWUw
References: <C7B14E2B.8A94%stefan@aaa-sec.com> <4B8BCF38.5030104@briansmith.org>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "Brian Smith" <brian@briansmith.org>, "Stefan Santesson" <stefan@aaa-sec.com>
X-OriginalArrivalTime: 02 Mar 2010 17:30:39.0438 (UTC) FILETIME=[13A5DEE0:01CABA2E]
Cc: Simon Josefsson <simon@josefsson.org>, tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
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: Tue, 02 Mar 2010 17:30:51 -0000

It looks to me that the client-side hash computation option is simpler if we don't try to build in agility and negotiation.  If we feel we need these then having the server assign an identity for these values seems simpler. 

Joe

> -----Original Message-----
> From: Brian Smith [mailto:brian@briansmith.org]
> Sent: Monday, March 01, 2010 6:29 AM
> To: Stefan Santesson
> Cc: Joseph Salowey (jsalowey); Simon Josefsson; tls@ietf.org
> Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
> 
> Stefan Santesson wrote:
> > It seems like an unnecessary complexity.
> >
> > The original approach have two functions
> > 1) Client informs the server what information it has cached
> > 2) Server accepts caching and replaces the data with the hash provided
> by
> > the client
> >
> > In the alternative approach this is expanded to:
> > 1) The client tells server that it wants to cache data
> > 2) The server provides hashes/identifiers of info the client may cache
> > 3) The client signals that it has cached info with identifiers provided
> by
> > the server
> > 4) The server replaces cached data
> >
> > I see no reason to make the protocol any more complex than it need to
> be.
> >
> In the alternative approach, there is no need to pass multiple hashes of
> the same item back/forth, so the syntax becomes simpler. Also, the
> client and server do not have to agree on a hash algorithm at all, which
> is a big simplification. The client doesn't have to calculate anything,
> which is a further simplification.
> 
> Many clients won't want to cache this information unless the server says
> that it supports the extension. That is why Adam Langley and others have
> asked for a ServerHello extension that indicates the items for which the
> server supports caching. It is very easy for the server to just stuff
> the identifiers inside that extension.
> 
> Regards,
> Brian