Re: [TLS] Cached-info substitution

Brian Smith <brian@briansmith.org> Fri, 19 February 2010 16:43 UTC

Return-Path: <brian@briansmith.org>
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 EDECC3A8195 for <tls@core3.amsl.com>; Fri, 19 Feb 2010 08:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 6hhpg0oQicyn for <tls@core3.amsl.com>; Fri, 19 Feb 2010 08:43:03 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id EEE0F28C0FB for <tls@ietf.org>; Fri, 19 Feb 2010 08:43:02 -0800 (PST)
Received: from [192.168.1.65] (unknown [70.134.205.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6455D22E25A; Fri, 19 Feb 2010 11:44:43 -0500 (EST)
Message-ID: <4B7EBFFB.3070601@briansmith.org>
Date: Fri, 19 Feb 2010 10:44:43 -0600
From: Brian Smith <brian@briansmith.org>
User-Agent: Postbox 1.1.1 (Windows/20100208)
MIME-Version: 1.0
To: Adam Langley <agl@google.com>
References: <4B7D8AAD.80204@briansmith.org> <C7A4666D.8663%stefan@aaa-sec.com> <a84d7bc61002190827t66450279vf3861d7e34425f04@mail.gmail.com>
In-Reply-To: <a84d7bc61002190827t66450279vf3861d7e34425f04@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Cached-info substitution
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: Fri, 19 Feb 2010 16:43:04 -0000

Adam Langley wrote:
> 3) Wedge the cached values into the current structures somehow. Brian
> suggests using zero lengths as a magic marker. However, the hash value
> would still need to follow because the client could have predicted one
> of several values. I think this is a poor man's version of option two.
>
>    
I had been making the (apparently incorrect) assumption that only one 
CachedObject per CachedInformationType value was allowed in the client 
hello. I thought the intention here was to have the client always 
cache/send the value for each information type that was most recently 
received from the server (perhaps out-of-band). Is there a need for more 
flexibility than that? AFAICT, for the uses identified so far, there isn't.

Regards,
Brian