Re: [TLS] New Cached info draft

Michael D'Errico <> Wed, 31 March 2010 15:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D47E3A69DA for <>; Wed, 31 Mar 2010 08:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.866
X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id whu8+tB5JFSd for <>; Wed, 31 Mar 2010 08:46:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B27F73A69B3 for <>; Wed, 31 Mar 2010 08:46:11 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id E709DA63BD for <>; Wed, 31 Mar 2010 11:46:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=370RhjDD4eRE 26PIAmpk+QzjhKY=; b=bc2NULjxysDJZJhvQFN7K/mjTSoIiF4nTYLUZZFcwrYu Lua9V/c1RP8PXYzBgTNOK2m7ZwVC+/XxzGLDM1lFsuK9QOZUDg5R99HNR3cT4vIT LSDLmNPUhT2Ae4Q4u0OVWIp2Yp/PHxayGdXaEDcnUEWff2hWsK0Ql2AnEk0hbXI=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=OzIJ4/ cz9finrQush5tfdYmC0zoMmpcZ9jtFxkbivsZ8D4r3FWWgctdIeTYiA4gWsgNyLG MeVXn7hNxMillrQAiXztINJNtR+fDjMu37aXRl73m4DWK5+Zkf0IIVsT5WzZbWXy BKtr2akh73GPeplfF5FeWaWp8ffpcNSSEJVCg=
Received: from a-pb-sasl-quonix. (unknown []) by (Postfix) with ESMTP id 6EA20A63BC for <>; Wed, 31 Mar 2010 11:46:41 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id ED285A63BB for <>; Wed, 31 Mar 2010 11:46:39 -0400 (EDT)
Message-ID: <>
Date: Wed, 31 Mar 2010 08:52:37 -0700
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 999BEDA6-3CDC-11DF-BE3E-D033EE7EF46B-38729857!
Subject: Re: [TLS] New Cached info draft
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: Wed, 31 Mar 2010 15:46:13 -0000

Stefan Santesson wrote:
> On 10-03-30 7:30 PM, "Brian Smith" <> wrote:
>> It is good to keep the maximum size of extensions small so that the server
>> can allocate and reuse fixed-size buffers that are as small as possible. I
>> don't see the use for allowing multiple values per information type, but at
>> least I think a small cap on the total size of the extension_data (say, 1KB)
>> would be useful. There's no need for a server to waste resources to support
>> clients that send dozens, hundreds, or thousands of digests.
> I think that is a good limitation. Suggesting:
>       struct {
>            CachedInformationType type;
>            opaque digest_value<0..8>;
>       } CachedObject;
>       struct {
>            CachedObject cached_info<1..1024>;
>       } CachedInformation;

I haven't been able to totally keep up with the progress of this draft or
to follow the discussion, but I think it's a bad idea to artificially limit
the size of anything to 1024 bytes.  We can handle 8-bit, 16-bit and 24-bit
sizes, and there is no precedent for choosing anything other than the full
range.  A single certificate can be 16MB!

If somebody wants to use small fixed-size buffers, then they can check the
length of the vector to see if it will fit.  If it won't fit, then they
have to deal with it somehow.  Putting a cap of 1024 bytes in the spec.
does nothing to change this -- you still have to check the size since an
attacker isn't going to play by the rules.  This idea has buffer overflow
written all over it.