Re: [TLS] New Cached info draft

Michael D'Errico <mike-list@pobox.com> Wed, 31 March 2010 15:46 UTC

Return-Path: <mike-list@pobox.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 0D47E3A69DA for <tls@core3.amsl.com>; Wed, 31 Mar 2010 08:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.866
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whu8+tB5JFSd for <tls@core3.amsl.com>; Wed, 31 Mar 2010 08:46:11 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id B27F73A69B3 for <tls@ietf.org>; Wed, 31 Mar 2010 08:46:11 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id E709DA63BD for <tls@ietf.org>; Wed, 31 Mar 2010 11:46:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; 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; d=pobox.com; 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 [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 6EA20A63BC for <tls@ietf.org>; Wed, 31 Mar 2010 11:46:41 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id ED285A63BB for <tls@ietf.org>; Wed, 31 Mar 2010 11:46:39 -0400 (EDT)
Message-ID: <4BB36FC5.3040209@pobox.com>
Date: Wed, 31 Mar 2010 08:52:37 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: tls@ietf.org
References: <C7D8D7A4.9C4D%stefan@aaa-sec.com>
In-Reply-To: <C7D8D7A4.9C4D%stefan@aaa-sec.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 999BEDA6-3CDC-11DF-BE3E-D033EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com
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 15:46:13 -0000

Stefan Santesson wrote:
> On 10-03-30 7:30 PM, "Brian Smith" <brian@briansmith.org>; 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.

Mike