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