Re: [TLS] New Cached info draft
"Brian Smith" <brian@briansmith.org> Tue, 30 March 2010 16:33 UTC
Return-Path: <brian@briansmith.org>
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 88B9A3A6AA4 for <tls@core3.amsl.com>; Tue, 30 Mar 2010 09:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Level:
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 UZW9i+a0FmNB for <tls@core3.amsl.com>; Tue, 30 Mar 2010 09:33:48 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 4397E3A68EF for <tls@ietf.org>; Tue, 30 Mar 2010 09:33:47 -0700 (PDT)
Received: from T60 (unknown [70.134.204.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CB6CD509DA; Tue, 30 Mar 2010 12:34:09 -0400 (EDT)
From: Brian Smith <brian@briansmith.org>
To: 'Stefan Santesson' <stefan@aaa-sec.com>, tls@ietf.org
References: <877houyzek.fsf@mocca.josefsson.org> <C7D79BB3.9B56%stefan@aaa-sec.com>
In-Reply-To: <C7D79BB3.9B56%stefan@aaa-sec.com>
Date: Tue, 30 Mar 2010 11:34:05 -0500
Message-ID: <000f01cad026$d52f1e10$7f8d5a30$@briansmith.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
thread-index: AQEfpeSCvJRvs2rVB5QorNdV0l2lBQEk6grRAVkkdTI=
Content-Language: en-us
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: Tue, 30 Mar 2010 16:33:49 -0000
Stefan Santesson wrote: > I would prefer that we stick to the current draft (FNV) as it is more than > good enough, free, fast, easy to implement, provides interop and effectively > avoids all requirements for agility complexity. I agree. It is good to see the syntax was simplified as a result. I have some suggestions: * The draft says that CachedInformation.cached_info can be up to (2^16-1)*9 = 590KB in size. extension_data can't be larger than 64KB, so the max bound for the CachedInformation.cached_info array must be 7281 or less. But, really, sending more than a few hashes per type of cached info is likely to run into DoS countermeasures. It would be better to have the specification require and/or at least recommend that there not be more than one (or at most a few) hashes per information type in the client hello. * The draft says "An empty cached_information extension indicates that the server supports information caching but provides no information about what information types it supports." This is not really helpful. It would be better to make a non-empty server cached_information extension a SHOULD-level requirement, because it is very helpful for clients to know what they should cache, and what they shouldn't. * The draft says "A present non-empty digest_value indicates that the server will honor caching of objects of the specified type that matches the present digest value." I don't see why this is necessary. The server should always be supporting the digests of the values that it most recently returned, for the information items it claims to support, so the semantics for empty digest_values in the server extension are good enough. And, this would let you simplify the syntax to: struct { CachedInformationType type; opaque digest_value<8>; <-- always 8 octets } CachedObject; struct { CachedObject cached_info<1..2^16-1>; } ClientCachedInformation; struct { CachedInformationType cached_info<0..255>; } ServerCachedInformation; Regards, Brian
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Stefan Santesson
- [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Kemp, David P.
- Re: [TLS] New Cached info draft Adam Langley
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Marsh Ray
- Re: [TLS] New Cached info draft Marsh Ray
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Simon Josefsson
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Adam Langley
- Re: [TLS] New Cached info draft Brian Smith
- Re: [TLS] New Cached info draft Brian Smith
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Martin Rex
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Brian Smith
- Re: [TLS] New Cached info draft Martin Rex
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Brian Smith
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Michael D'Errico
- Re: [TLS] New Cached info draft Marsh Ray
- Re: [TLS] New Cached info draft Brian Smith
- Re: [TLS] New Cached info draft Adam Langley
- Re: [TLS] New Cached info draft Stefan Santesson
- Re: [TLS] New Cached info draft Martin Rex
- Re: [TLS] New Cached info draft Martin Rex
- Re: [TLS] New Cached info draft Marsh Ray
- Re: [TLS] New Cached info draft Martin Rex