Re: [TLS] First TLS cached information draft posted

Simon Josefsson <simon@josefsson.org> Tue, 09 June 2009 10:59 UTC

Return-Path: <simon@josefsson.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 5E5323A6CBE for <tls@core3.amsl.com>; Tue, 9 Jun 2009 03:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 p4tDSYBRGr1C for <tls@core3.amsl.com>; Tue, 9 Jun 2009 03:59:58 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 23CDE3A6C73 for <TLS@ietf.org>; Tue, 9 Jun 2009 03:59:57 -0700 (PDT)
Received: from mocca.josefsson.org (c80-216-24-60.bredband.comhem.se [80.216.24.60]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n59Axqic000439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jun 2009 12:59:59 +0200
From: Simon Josefsson <simon@josefsson.org>
To: martin.rex@sap.com
References: <87k53lkizg.fsf@mocca.josefsson.org> <200906091002.n59A2b5M019183@fs4113.wdf.sap.corp>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090609:tls@ietf.org::7CPufywfXD/YBYAW:LIpn
X-Hashcash: 1:22:090609:martin.rex@sap.com::9gp5qmjLs1oREoBX:MnLG
Date: Tue, 09 Jun 2009 12:59:52 +0200
In-Reply-To: <200906091002.n59A2b5M019183@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 9 Jun 2009 12:02:37 +0200 (MEST)")
Message-ID: <87ab4hisev.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: TLS@ietf.org
Subject: Re: [TLS] First TLS cached information draft 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: Tue, 09 Jun 2009 10:59:59 -0000

Martin Rex <Martin.Rex@sap.com> writes:

> Simon Josefsson wrote:
>> Martin Rex wrote: 
>> > The impact on implementations of TLS should be as small as possible.
>> > To me, a requirement for a TLS server to precompute hashes over
>> > parts of future handshake messages during ServerHello looks like
>> > a significant additional burden, and personally, I do not yet see
>> > any benefit this might provide.
>> 
>> Good point, but how would a client know whether a server replaced the
>> cached information with a hash or not if there is no signaling whether
>> this happened or not?
>
> The client knows which Hash it would find, if the server would sent
> the hash, so it could check for that.  Even a collision of the
> hash and the original handshake data would not cause a problem
> with this "heuristical" determination.
>
> I'm wondering about the following: we should give a strong recommendation
> about the minimum size of an object in order for caching to make any
> sense at all, like >= 2x the size of the hash.
>
> At least 2x, because the hash appears (at least) twice in a full SSL
> handshake (ClientHello and the actual handshake message with the
> cached information).
>
> For a SSL session resume, the extension will create an unconditional
> burden, because the ClientHello extension would need to be present
> in every ClientHello, in order to actually save on the full handshake
> in case the server decides to require one (e.g. session expired on
> server side).
>
> Maybe the minimum size should be rather 3x hash size, considering
> the rest of the protocol overhead.

This seems like a good idea -- and it solves the problem in the client
to identify whether the server replaced the data or not.  If the minimum
size is 3x hash size, the client can look at the length of the data.  If
it is longer than 3x hash size, it knows the server opted out from
sending the hash.  If it is shorter than 3x hash size, it knows the
server actually did replace the data with a hash value.

It seems wasteful that the same hash value is sent back and forth
_three_ times during a handshake, and possibly that could be optimized.
But that would add complexity.

/Simon