Re: [TLS] New Cached info draft

Stefan Santesson <> Tue, 30 March 2010 19:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 385E13A6877 for <>; Tue, 30 Mar 2010 12:23:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5jLAy1PLP77d for <>; Tue, 30 Mar 2010 12:23:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 70B8C3A6AB6 for <>; Tue, 30 Mar 2010 12:23:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A49FE2BCA83 for <>; Tue, 30 Mar 2010 21:21:30 +0200 (CEST)
Received: (qmail 64153 invoked from network); 30 Mar 2010 19:21:22 -0000
Received: from (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <>; 30 Mar 2010 19:21:22 -0000
User-Agent: Microsoft-Entourage/
Date: Tue, 30 Mar 2010 21:21:22 +0100
From: Stefan Santesson <>
To: Brian Smith <>, <>
Message-ID: <>
Thread-Topic: [TLS] New Cached info draft
Thread-Index: AQH2zpkx6SXE20QoIjYvnNXk//OcBgFxK2uqAU89Q72RnNvl4w==
In-Reply-To: <003501cad037$1b37c960$51a75c20$>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
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: Tue, 30 Mar 2010 19:23:50 -0000


I see that I misunderstood you a bit.

I agree that it could be wise to limit the max size of this extension. It
does not have to be that large.

I'll get back to the rest later.


On 10-03-30 7:30 PM, "Brian Smith" <> wrote:

> Stefan Santesson wrote:
>> On 10-03-30 6:23 PM, "Martin Rex" <> wrote:
>>> I do not think that he suggested to not return the extension _and_
>>> replace cached data.
>> I interpreted the ServerCachedInformation structure as a separate
> extension
>> sent only by the server.
> No, I meant for the client and the server to use the same extension ID, but
> with different syntax for the extension_data. That is allowed. In fact the
> current draft already has slightly different syntax for the client and
> server extension data; the client digest_value is fixed at 8 bytes and the
> server digest value can be either 0 or 8 bytes.
>>>> On 10-03-30 5:34 PM, "Brian Smith" <> wrote:
>>>>> * The draft says that CachedInformation.cached_info can be up to
>>>>> 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.
>>> To me, allowing the client to cache distinct values for the same
>>> server leads to cache management problems.  How should a client expire
>>> outdated content from his cache?  If the client only caches one item
>>> per "server:port" pair, then expiring of outdated cached information
>>> is a non-issue.
>> It's a non-issue in any case. A timer for example works well. Nothing
>> prevents the client to refuse caching more than one object per type and
>> server, but that restriction doesn't strike me as necessary.
> 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.
>>>>> * 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.
>>> I would also appreciate semantics as suggested here.
>>> Allow the server to return a ServerHelloExtension that explicitly list
>>> the types of information for which the server supports caching, but
>>> _without_ a digest_value, both on discovery and on actual use of
>>> the caching extension by the client, so that the server does not
>>> have to pre-calculate this data of future handshake message
>>> while it is composing ServerHello.
>> The server doesn't have to send digest values in current draft.
> AFAICT, there's nothing in the draft that says that the client should use
> this information in any way. As long as the client is free to ignore the
> server-sent digest_values when present, it doesn't hurt. But, I don't see
> how it really helps either. It's better to keep the syntax as simple as
> possible.
> Again, it is best to require that the server explicitly list the information
> types for which it supports caching. It costs the server basically nothing
> to provide the few extra bytes, and it is very useful information for the
> client to have.
> Regards,
> Brian