Re: [TLS] New Cached info draft

Martin Rex <mrex@sap.com> Tue, 30 March 2010 17:23 UTC

Return-Path: <mrex@sap.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 74A943A6781 for <tls@core3.amsl.com>; Tue, 30 Mar 2010 10:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.439
X-Spam-Level:
X-Spam-Status: No, score=-8.439 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 FKvDQsU0kN2g for <tls@core3.amsl.com>; Tue, 30 Mar 2010 10:23:27 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id CF9E53A67B2 for <tls@ietf.org>; Tue, 30 Mar 2010 10:23:26 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o2UHNpkk028801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2010 19:23:51 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201003301723.o2UHNoc5008008@fs4113.wdf.sap.corp>
To: stefan@aaa-sec.com (Stefan Santesson)
Date: Tue, 30 Mar 2010 19:23:50 +0200 (MEST)
In-Reply-To: <C7D7FAE5.9BC6%stefan@aaa-sec.com> from "Stefan Santesson" at Mar 30, 10 07:00:53 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] New Cached info draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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:23:28 -0000

Stefan Santesson wrote:
> 
> 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.

To me it sounded like Brian disliked the ServerHelloExtension
to be allowed empty on the initial discovery, rather than telling
the client for which handshake data the server supports caching.

I do not think that he suggested to not return the extension _and_
replace cached data.


> On 10-03-30 5:34 PM, "Brian Smith" <brian@briansmith.org>; wrote:
> 
> > * 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.

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.


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


-Martin