Re: [TLS] New Cached info draft

Marsh Ray <marsh@extendedsubset.com> Wed, 31 March 2010 16:03 UTC

Return-Path: <marsh@extendedsubset.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 5A51E3A6A13 for <tls@core3.amsl.com>; Wed, 31 Mar 2010 09:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.494
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+V2yCwf7V+z for <tls@core3.amsl.com>; Wed, 31 Mar 2010 09:03:50 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 770693A684F for <tls@ietf.org>; Wed, 31 Mar 2010 09:03:50 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1Nx0Oz-00013L-2o; Wed, 31 Mar 2010 16:04:21 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C99C460B8; Wed, 31 Mar 2010 16:04:19 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/Mn1N7mNWS+OMjRazTQoJShjq0xYCejf0=
Message-ID: <4BB37285.5020906@extendedsubset.com>
Date: Wed, 31 Mar 2010 11:04:21 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Michael D'Errico <mike-list@pobox.com>
References: <C7D8D7A4.9C4D%stefan@aaa-sec.com> <4BB36FC5.3040209@pobox.com>
In-Reply-To: <4BB36FC5.3040209@pobox.com>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] New Cached info draft
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: 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