Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft

Stefan Santesson <stefan@aaa-sec.com> Mon, 01 March 2010 09:57 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 6BBCB3A8405 for <tls@core3.amsl.com>; Mon, 1 Mar 2010 01:57:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 LxJsODGzpIHX for <tls@core3.amsl.com>; Mon, 1 Mar 2010 01:57:55 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 7AA3E3A8636 for <tls@ietf.org>; Mon, 1 Mar 2010 01:57:54 -0800 (PST)
Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id C8D2F28B8CF for <tls@ietf.org>; Mon, 1 Mar 2010 10:57:56 +0100 (CET)
Received: (qmail 24441 invoked from network); 1 Mar 2010 09:57:53 -0000
Received: from unknown (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.2.114]) (envelope-sender <stefan@aaa-sec.com>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <jsalowey@cisco.com>; 1 Mar 2010 09:57:53 -0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Mon, 01 Mar 2010 10:57:47 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, Simon Josefsson <simon@josefsson.org>, Brian Smith <brian@briansmith.org>
Message-ID: <C7B14E2B.8A94%stefan@aaa-sec.com>
Thread-Topic: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
Thread-Index: Acq23Mnomt5WrrPJ+0WEPjfWEFUKbgCJT+KAAAjm8Bw=
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE509B5C165@xmb-sjc-225.amer.cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" 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: Mon, 01 Mar 2010 09:57:56 -0000

It seems like an unnecessary complexity.

The original approach have two functions
1) Client informs the server what information it has cached
2) Server accepts caching and replaces the data with the hash provided by
the client


In the alternative approach this is expanded to:
1) The client tells server that it wants to cache data
2) The server provides hashes/identifiers of info the client may cache
3) The client signals that it has cached info with identifiers provided by
the server
4) The server replaces cached data

I see no reason to make the protocol any more complex than it need to be.

/Stefan


On 10-03-01 6:47 AM, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>; wrote:

> Hi Stefan,
> 
> What is the disadvantage if the client cannot cache information from a
> handshake in which the server does not include the hash?
> 
> Thanks,
> 
> Joe
> 
>> -----Original Message-----
>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
>> Stefan Santesson
>> Sent: Friday, February 26, 2010 4:11 AM
>> To: Simon Josefsson; Brian Smith
>> Cc: tls@ietf.org
>> Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track"
> draft
>> 
>> Simon and Brian,
>> 
>> On 10-02-26 10:38 AM, "Simon Josefsson" <simon@josefsson.org>; wrote:
>> 
>>>> My second suggestion is to have the server calculate the hash, and
>>>> give the calculated hash to the client along with the content. Then
>>>> the client and the server don't have to agree on any algorithms at
>>>> all, and the server can choose whatever algorithm it wants.
>>> 
>>> I like this approach.  The server gets to chose the hash, and the
> client
>>> will have to comply.  It is easy to implement, and it is possible to
>>> transition to other checksum algorithms over time.
>> 
>> 
>> I'm sorry, but this seems like a really bad idea.
>> 
>> The idea of this draft is that a client should be able to cash
> information
>> form a perfectly normal handshake (one where the server does not
> provide a
>> hash that may represent what it sends).
>> 
>> /Stefan
>> 
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls