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

Simon Josefsson <> Tue, 02 February 2010 13:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D682E3A6940 for <>; Tue, 2 Feb 2010 05:19:26 -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 sHvnB2Dd+36Y for <>; Tue, 2 Feb 2010 05:19:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EA5CE3A6885 for <>; Tue, 2 Feb 2010 05:19:21 -0800 (PST)
Received: from mocca ( []) (authenticated bits=0) by (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o12DJmC0015842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 2 Feb 2010 14:19:51 +0100
From: Simon Josefsson <>
To: "Brian Smith" <>
References: <001901caa3e4$c0363750$40a2a5f0$@org>
OpenPGP: id=B565716F; url=
Date: Tue, 02 Feb 2010 14:19:48 +0100
In-Reply-To: <001901caa3e4$c0363750$40a2a5f0$@org> (Brian Smith's message of "Tue, 2 Feb 2010 02:50:15 -0600")
Message-ID: <>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.95.3 at yxa-v
X-Virus-Status: Clean
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 13:19:27 -0000

"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.

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).

I'm not sure how this relates to the rest of your e-mail though...