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

Brian Smith <brian@briansmith.org> Tue, 23 February 2010 17:17 UTC

Return-Path: <brian@briansmith.org>
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 07D473A830E for <tls@core3.amsl.com>; Tue, 23 Feb 2010 09:17:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 WDpVmb3H1WaT for <tls@core3.amsl.com>; Tue, 23 Feb 2010 09:17:51 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id AA5D23A830D for <tls@ietf.org>; Tue, 23 Feb 2010 09:17:50 -0800 (PST)
Received: from [192.168.1.65] (unknown [70.252.11.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DAABA509DD; Tue, 23 Feb 2010 12:19:52 -0500 (EST)
Message-ID: <4B840E38.8070107@briansmith.org>
Date: Tue, 23 Feb 2010 11:19:52 -0600
From: Brian Smith <brian@briansmith.org>
User-Agent: Postbox 1.1.1 (Windows/20100208)
MIME-Version: 1.0
To: mrex@sap.com
References: <201002191745.o1JHjQcH017621@fs4113.wdf.sap.corp>
In-Reply-To: <201002191745.o1JHjQcH017621@fs4113.wdf.sap.corp>
Content-Type: multipart/alternative; boundary="------------030706090008060908070208"
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: Tue, 23 Feb 2010 17:17:52 -0000

Martin Rex wrote:
> Brian Smith wrote:
>    
>> Perhaps this all can be avoided by simply not having the client
>> calculate hashes at all for . For example, would this work?:
>>
>> struct {
>>       CachedInformationType type;
>>       opaque token<0..255>;
>> } CachedObject;
>>      
>
> I've been advocating the use of a hash value over the real data
> so that the handshake will do the right thing automatically if
> the data cached by the client and the data the server is going
> to return no longer match: the server is going to send the new
> data in full, and the client can update his cache.
>
> You definitely do not want a handshake failure (which always
> requires application involvement to recover from and a
> new connection) if the data cached by the client is out of
> sync with what the server wants to return.
>    
This already happens with session resumption, when the server re-uses a 
session ID (so that the client's mapping of session ID -> session state 
doesn't match the server's mapping of session ID -> session state). The 
solution there was basically to tell the server "don't do that," and I 
think the same solution can be used here. That is why I suggested 
recommending the server to use a SHA-2 hash of the cached data.

> The client needs to be able to distinguish omitted handshake
> data (which he has cached) from new real data
I believe my proposed scheme already does this. If the client cached a 
zero-length string, he will have a non-zero-length token for it. If the 
server wants to send a new non-zero-length value for that cached item, 
then it would either send no token at all for that item (indicating that 
the new value can't be cached) or it would send a new token.
> and the server should not be forced to precompute all handshake
> messages when composing the server hello handshake message
> in order to confirm matches to the data that the client
> has indicated to have cached.
>    
The items that are useful to be cached are all sent directly after the 
server hello (certificate, certificate request, and key exchange). 
There's nothing else that's large in the handshake. And, in practice, 
the server has to do this anyway if it supports session resumption. 
Regardless, it isn't a burden for the server anyway. Every time the 
server sends a new cachable item, it would calculate the token and cache it.

Regardless of the SHA1 issue, if the extension can be designed so that 
the client doesn't have to do any calculations in order to use the 
extension, that is a big win, because it makes the client much easier to 
implement and much simpler to maintain. It is much easier to perform 
maintenance on servers than on clients, especially clients that have 
their TLS implementation baked into firmware of consumer devices.

Cheers,
Brian