Re: [TLS] Cached Info extension - Draft 01

Stefan Santesson <stefan@aaa-sec.com> Thu, 02 July 2009 06:16 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 A9BF13A687C for <tls@core3.amsl.com>; Wed, 1 Jul 2009 23:16:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.842
X-Spam-Level:
X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.407, 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 TTEnWLwgMnVQ for <tls@core3.amsl.com>; Wed, 1 Jul 2009 23:16:56 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id B83C13A6C20 for <tls@ietf.org>; Wed, 1 Jul 2009 23:15:25 -0700 (PDT)
Received: (qmail 57496 invoked from network); 2 Jul 2009 06:15:46 -0000
Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender <stefan@aaa-sec.com>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <tls@ietf.org>; 2 Jul 2009 06:15:46 -0000
Received: (qmail 38291 invoked from network); 2 Jul 2009 06:15:44 -0000
Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender <stefan@aaa-sec.com>) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <martin.rex@sap.com>; 2 Jul 2009 06:15:44 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Thu, 02 Jul 2009 08:15:43 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: martin.rex@sap.com
Message-ID: <C6721D2F.2ECF%stefan@aaa-sec.com>
Thread-Topic: [TLS] Cached Info extension - Draft 01
Thread-Index: Acn63IeCQkNa6oM20keMPL4NQf09UA==
In-Reply-To: <200907012300.n61N0rf7003442@fs4113.wdf.sap.corp>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: simon@josefsson.org, tls@ietf.org
Subject: Re: [TLS] Cached Info extension - Draft 01
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: Thu, 02 Jul 2009 06:16:56 -0000

Martin,

On 09-07-02 1:00 AM, "Martin Rex" <Martin.Rex@sap.com> wrote:

> If the real data is no longer part of the SSL handshake, but instead
> either a weak hash or even a static "cache handle", then there is
> a change in the cryptographic properties of the SSL handshake using
> cached handshake data and the full handshake with the real data.

I don't believe this conclusion is correct.

The handshake will proceed exactly as it would have if the real data was
exchanged, preserving the cryptographic properties of a full handshake with
the original data.

This is true with only one exception. It changes the data used to calculate
the finished message. With cached data, the finished message is calculated
over the "weak" hashes instead of the original data.

For this to be turned into an attack, you have to make it plausible that one
could force two different TLS sessions to produce colliding finished
messages through a "weak" caching hash. This can't be the case if the hash
algorithm used to calculate the finished message is solid.