Re: [TLS] New cached info draft 02 posted

Stefan Santesson <stefan@aaa-sec.com> Wed, 30 September 2009 06:35 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 7E8F83A6847 for <tls@core3.amsl.com>; Tue, 29 Sep 2009 23:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.074
X-Spam-Level:
X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 XKQoJcpsf6NV for <tls@core3.amsl.com>; Tue, 29 Sep 2009 23:35:32 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id AA7F23A682B for <tls@ietf.org>; Tue, 29 Sep 2009 23:35:31 -0700 (PDT)
Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 3A95228A056 for <tls@ietf.org>; Wed, 30 Sep 2009 08:36:54 +0200 (CEST)
Received: (qmail 50178 invoked from network); 30 Sep 2009 06:36:52 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (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 <martin.rex@sap.com>; 30 Sep 2009 06:36:52 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Wed, 30 Sep 2009 08:36:51 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: <martin.rex@sap.com>
Message-ID: <C6E8C923.4F2B%stefan@aaa-sec.com>
Thread-Topic: [TLS] New cached info draft 02 posted
Thread-Index: AcpBmGR56hgyUEJVfk6opiCsZCoTrw==
In-Reply-To: <200909290107.n8T17HLM021236@fs4113.wdf.sap.corp>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] New cached info draft 02 posted
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, 30 Sep 2009 06:35:33 -0000

Martin,

For clarification. I have understood your position before that the server
should not need to determine if it will replace data with its hash until the
very moment that data is to be sent in the handshake.

I would then understand your position in the following way:

In the server hello, the server should tell in general;
  (a) whether the server supports the caching extension
  (b) for which elements the server supports caching
  (c) which hash algorithm the server supports for caching

This would not tell anything whether the server actually will replace any
data with its hash in the following handshake.


However, on your argument:
> on the first connect to a server, so that the client does
> not have to make guesses and populate/maintain its cache
> for servers that do not support this extension.

This is already the case for the current draft, as (a) is already satisfied.

Supporting (b) and (c) will probably require a different syntax in the
client and server hello extensions.

/Stefan


On 09-09-29 3:07 AM, "Martin Rex" <Martin.Rex@sap.com>; wrote:

> Stefan Santesson wrote:
>> 
>> I have just posted a new version 02 of the cached info draft.
>> http://www.ietf.org/id/draft-ietf-tls-cached-info-02.txt
>> 
>> As there has been no further comments on the draft responding to my
>> questions after last IETF, I have nothing further to add.
>> 
>> I think this document is ready for a WGLC.
> 
> 
> I already mentioned twice in the discussion of this document
> that I would REALLY appreciate if it was enhanced to provide
> a much better cache control (for the client, that is).
> 
> The extension should allow the client to determine
>  (a) whether the server supports the caching extension
>  (b) for which elements the server supports caching
>  (c) which hash algorithm the server supports for caching
> 
> on the first connect to a server, so that the client does
> not have to make guesses and populate/maintain its cache
> for servers that do not support this extension.
> 
> -Martin
> 
> 
>