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

"Brian Smith" <> Tue, 02 February 2010 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 197263A6839 for <>; Tue, 2 Feb 2010 07:16:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TKVJPGWPpA-P for <>; Tue, 2 Feb 2010 07:15:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A7D9E3A6801 for <>; Tue, 2 Feb 2010 07:15:57 -0800 (PST)
Received: from T60 (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E2EBE509DE; Tue, 2 Feb 2010 10:16:26 -0500 (EST)
From: "Brian Smith" <>
To: "'Simon Josefsson'" <>
References: <001901caa3e4$c0363750$40a2a5f0$@org> <>
In-Reply-To: <>
Date: Tue, 2 Feb 2010 09:16:23 -0600
Message-ID: <000301caa41a$b4fe2560$1efa7020$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: en-us
Thread-Index: AcqkCmqvI0oiP3nSQte8t65pPK0DhQADwrQQ
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Feb 2010 15:16:02 -0000

Simon Josefsson wrote:
> "Brian Smith" <> writes:
> > I am very interested in the ideas that motivate the cached info
> > extension.
> Stefan can speak for his reasons, but I see significant advantage in
> being able to cache the list of trusted CA certs that is sent from
> server to client.  For whatever reasons (which likely include poor
> server configuration), I've seen TLS handshakes in the wild that are as
> large as 30-40kb which cause some operational pains.

I didn't phrase this clearly. What I meant to say is "I find the cached info
extension interesting because optimizing the handshake is very important to

> The server certificate _chain_ (note that it is the entire chain that
> is cached, not just the server certificate) also has potential of being
> large (and growing over time, it seems, as more and more interesting
> X.509 extensions are added).

Agreed. My suggestion is really just trying to extend the usefulness of this
extension to the case where the certificate chain is not large.