Re: [TLS] New Cached info draft

Stefan Santesson <stefan@aaa-sec.com> Wed, 31 March 2010 08:49 UTC

Return-Path: <stefan@aaa-sec.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 8769D3A67F9 for <tls@core3.amsl.com>; Wed, 31 Mar 2010 01:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.761
X-Spam-Level:
X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 4dgd-qbOWIOG for <tls@core3.amsl.com>; Wed, 31 Mar 2010 01:49:41 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by core3.amsl.com (Postfix) with ESMTP id 7AD763A67D4 for <tls@ietf.org>; Wed, 31 Mar 2010 01:49:40 -0700 (PDT)
Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 7AD8E2BFB00 for <tls@ietf.org>; Wed, 31 Mar 2010 10:42:49 +0200 (CEST)
Received: (qmail 25985 invoked from network); 31 Mar 2010 08:42:45 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.16]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <brian@briansmith.org>; 31 Mar 2010 08:42:45 -0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Wed, 31 Mar 2010 10:42:44 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Brian Smith <brian@briansmith.org>, <tls@ietf.org>
Message-ID: <C7D8D7A4.9C4D%stefan@aaa-sec.com>
Thread-Topic: [TLS] New Cached info draft
Thread-Index: AQH2zpkx6SXE20QoIjYvnNXk//OcBgFxK2uqAU89Q72RnbvLmw==
In-Reply-To: <003501cad037$1b37c960$51a75c20$@briansmith.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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 08:49:42 -0000

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;



> 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.
> 

It could help the client to update it's cache and retire no-longer supported
cached items.

This could be clarified in the text. E.g. That if the server return digest
values, it MUST return all supported digest values in order to allow the
client update it's current set of valid cached objects.


> 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.
> 

I'm open to include such requirement. Do others agree?

/Stefan