Re: [TLS] Cached-info substitution

Adam Langley <agl@google.com> Fri, 19 February 2010 16:51 UTC

Return-Path: <agl@google.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 A70F328C2A4 for <tls@core3.amsl.com>; Fri, 19 Feb 2010 08:51:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.088
X-Spam-Level:
X-Spam-Status: No, score=-105.088 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 NchNdtK4WYdv for <tls@core3.amsl.com>; Fri, 19 Feb 2010 08:51:14 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6ABBA28C309 for <tls@ietf.org>; Fri, 19 Feb 2010 08:51:14 -0800 (PST)
Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o1JGr0WZ005078 for <tls@ietf.org>; Fri, 19 Feb 2010 08:53:01 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1266598381; bh=FrHSUb/AxoLtxqx/0dbjTZS+oFo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=jRYltufKXrq3wU6rspD7b7VmVTE35G/Lpxl7CltWiUkZ2Ca4pW9Wkw5vxoS2w9DPu 4mAeCMylCLCnEt6Dtih9Q==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=L458D/iZyAF5025nR3HjN+RgVLlTLCGIQ/Z0GaquLWcFdIg+jDDHvC5tGw8YXSK5E Zs30xh7hjrPTWiG/tnlJw==
Received: from pwj7 (pwj7.prod.google.com [10.241.219.71]) by wpaz24.hot.corp.google.com with ESMTP id o1JGqwAG014634 for <tls@ietf.org>; Fri, 19 Feb 2010 08:53:00 -0800
Received: by pwj7 with SMTP id 7so233060pwj.28 for <tls@ietf.org>; Fri, 19 Feb 2010 08:52:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.61.20 with SMTP id j20mr2699606wfa.105.1266598378574; Fri, 19 Feb 2010 08:52:58 -0800 (PST)
In-Reply-To: <4B7EBFFB.3070601@briansmith.org>
References: <4B7D8AAD.80204@briansmith.org> <C7A4666D.8663%stefan@aaa-sec.com> <a84d7bc61002190827t66450279vf3861d7e34425f04@mail.gmail.com> <4B7EBFFB.3070601@briansmith.org>
Date: Fri, 19 Feb 2010 11:52:58 -0500
Message-ID: <a84d7bc61002190852y684103ecmc95c23853c24dc5a@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
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:51:15 -0000

On Fri, Feb 19, 2010 at 11:44 AM, Brian Smith <brian@briansmith.org>; wrote:
> 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.

I had interpreted the draft to mean that multiple possible
CachedObjects with the same type could be presented.

I can imagine some use cases where this would be helpful: an
organisation which can multiple serving clusters for the same domain
name, where each cluster has a different certificate. Or when a new
certificate was being rolled out to a number of servers, but clients
were getting load balanced between them.

However, given that this is only an optimisation, these cases might be
sufficiently unimportant that we can forbid multiple CachedObjects
with the same type and reap the benefits in a simpler substitution
scheme. I think I would be happy with that unless some particularly
compelling use case arises.


AGL