Re: [TLS] New Cached info draft

"Brian Smith" <> Tue, 30 March 2010 16:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88B9A3A6AA4 for <>; Tue, 30 Mar 2010 09:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UZW9i+a0FmNB for <>; Tue, 30 Mar 2010 09:33:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4397E3A68EF for <>; Tue, 30 Mar 2010 09:33:47 -0700 (PDT)
Received: from T60 (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id CB6CD509DA; Tue, 30 Mar 2010 12:34:09 -0400 (EDT)
From: "Brian Smith" <>
To: "'Stefan Santesson'" <>, <>
References: <> <>
In-Reply-To: <>
Date: Tue, 30 Mar 2010 11:34:05 -0500
Message-ID: <000f01cad026$d52f1e10$7f8d5a30$>
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-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: 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
> 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;