Re: [TLS] New Cached info draft

Stefan Santesson <stefan@aaa-sec.com> Tue, 30 March 2010 17:01 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 024B23A67F3 for <tls@core3.amsl.com>; Tue, 30 Mar 2010 10:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.283
X-Spam-Level:
X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=0.836, 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 1AgK+PiXiFly for <tls@core3.amsl.com>; Tue, 30 Mar 2010 10:01:48 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by core3.amsl.com (Postfix) with ESMTP id 761983A67F0 for <tls@ietf.org>; Tue, 30 Mar 2010 10:01:47 -0700 (PDT)
Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 81327322390 for <tls@ietf.org>; Tue, 30 Mar 2010 19:01:02 +0200 (CEST)
Received: (qmail 84891 invoked from network); 30 Mar 2010 17:00:55 -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 s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <brian@briansmith.org>; 30 Mar 2010 17:00:55 -0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Tue, 30 Mar 2010 19:00:53 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Brian Smith <brian@briansmith.org>, <tls@ietf.org>
Message-ID: <C7D7FAE5.9BC6%stefan@aaa-sec.com>
Thread-Topic: [TLS] New Cached info draft
Thread-Index: AQEfpeSCvJRvs2rVB5QorNdV0l2lBQEk6grRAVkkdTKTTRjfng==
In-Reply-To: <000f01cad026$d52f1e10$7f8d5a30$@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: Tue, 30 Mar 2010 17:01:50 -0000

Brian,

I do not agree with your change proposals.

The most important reason being that the server need to reply with the same
extension that the client sends, everything else is a violation of TLS.

RFC 5246:
   An extension type MUST NOT appear in the ServerHello unless the same
   extension type appeared in the corresponding ClientHello.

There are other reasons, but this is the most important one. Yes, we made a
stretch of that in the renego rfc, but I remember it was agreed to be a one
time thing.

I don't see any big reason to change the current syntax.

/Stefan

 

On 10-03-30 5:34 PM, "Brian Smith" <brian@briansmith.org>; wrote:

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