Re: [TLS] Wrapping up cached info

Stefan Santesson <stefan@aaa-sec.com> Mon, 17 May 2010 20:38 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 872C628C0F7 for <tls@core3.amsl.com>; Mon, 17 May 2010 13:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.393
X-Spam-Level:
X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 lxvEaB8hfJ+l for <tls@core3.amsl.com>; Mon, 17 May 2010 13:38:49 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id 5FBA428C164 for <tls@ietf.org>; Mon, 17 May 2010 13:34:51 -0700 (PDT)
Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 3A21737D2DC for <tls@ietf.org>; Mon, 17 May 2010 22:34:50 +0200 (CEST)
Received: (qmail 71792 invoked from network); 17 May 2010 20:34:42 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.8]) (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 <mrex@sap.com>; 17 May 2010 20:34:42 -0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Mon, 17 May 2010 22:34:39 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: <mrex@sap.com>, Joseph Salowey <jsalowey@cisco.com>
Message-ID: <C81774FF.AE31%stefan@aaa-sec.com>
Thread-Topic: [TLS] Wrapping up cached info
Thread-Index: Acr2AF8iO6bF6i2yM0up48R7QWj7GQ==
In-Reply-To: <201005171916.o4HJG1Io008515@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] Wrapping up cached info
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, 17 May 2010 20:38:50 -0000

Guys,

Where I come from we have a say "don't cross the river to get to the water".
And to me this proposal to change the finished calculation is just that.

Look at it.

The proposal is to bind the cached data by adding a hash of the cached data
to the finished calculation.

The proposal is further to avoid hash agility by picking the hash algorithm
used by TLS's Finished message computation.


Now there are two ways to achieve this goal.

1) The crossing the river to get water approach:  Exchange FNV hashes of the
cached data in the handshake protocol exchange and then inject hashes of the
same data into the finished calculation through an alteration of the TLS
protocol.


2) The simple approach: Use the hash algorithm of the finished calculation
to hash the cached data (according to the current draft).


Alternative 2 securely bind the hashed data into the finished message
calculation without altering the algorithm.

Alternative 2 requires at most a hash algorithm identifier added to the
protocol, if at all. We don't need to add negotiation since we always use
the hash of the finished message calculation. Adding this identifier would
be the only change made to the current draft.

Alternative 2 don't require additional security analysis. If the hash used
to calculate the finished message is broken, then we are screwed anyway.

/Stefan









On 10-05-17 9:16 PM, "Martin Rex" <mrex@sap.com> wrote:

> Joseph Salowey wrote:
>> 
>> I agree with Uri, that if you determine you need SHA-256 then you should
>> plan for hash agility.  TLS 1.2 plans for hash agility.
>> 
>> What about Nico's proposal where a checksum is used to identify the
>> cached data and the actual handshake contains the actual data hashed
>> with the algorithm used in the PRF negotiated with the cipher suite?
>> 
>> This way we don't have to introduce hash agility into the extension, but
>> we have cryptographic hash agility where it matters in the Finished
>> computation.  Does it solve the problem?
> 
> Yes, I think so.
> This approach should solve the issue at the technical level.
> 
> Going more into detail, one would hash/mac only the data that got
> actually replaced in the handshake, each prefixed by a (locally computed)
> length field.
> 
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls