Re: [TLS] New Cached info draft

Marsh Ray <> Wed, 31 March 2010 16:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A51E3A6A13 for <>; Wed, 31 Mar 2010 09:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.494
X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i+V2yCwf7V+z for <>; Wed, 31 Mar 2010 09:03:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 770693A684F for <>; Wed, 31 Mar 2010 09:03:50 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1Nx0Oz-00013L-2o; Wed, 31 Mar 2010 16:04:21 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id C99C460B8; Wed, 31 Mar 2010 16:04:19 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1/Mn1N7mNWS+OMjRazTQoJShjq0xYCejf0=
Message-ID: <>
Date: Wed, 31 Mar 2010 11:04:21 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Michael D'Errico <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 16:03:51 -0000

On 3/31/2010 10:52 AM, Michael D'Errico wrote:
> Stefan Santesson wrote:
>> 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.

My understanding is that this structure is received before the parties
have authenticated each other. In this context, restrictive limits are
somewhat appropriate.

> 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!

I think in this case it's saying there can be a maximum of 1024 entries
in the list, each of which can take up to 9 bytes (with a one byte
length). So the receiver of this structure is only obligated to store
(or ignore) (2 + (1 + 8)*1024) bytes of data.

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

What ends up happening in the absence of a defined limit is that
products will either be subject to a DOS, or different limits will be
imposed by different products which harms interoperability.

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

At some point, someone has to be expected to write correct code. :-)

- Marsh