Re: [TLS] Cached Info extension - Draft 01

Stefan Santesson <stefan@aaa-sec.com> Wed, 01 July 2009 22:29 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 D967C3A6B4B for <tls@core3.amsl.com>; Wed, 1 Jul 2009 15:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.400, 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 Qc5AbulZT2jS for <tls@core3.amsl.com>; Wed, 1 Jul 2009 15:29:22 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id AB6D73A68B6 for <tls@ietf.org>; Wed, 1 Jul 2009 15:29:20 -0700 (PDT)
Received: (qmail 20030 invoked from network); 1 Jul 2009 22:29:45 -0000
Received: from s34.loopia.se (HELO s42.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>; 1 Jul 2009 22:29:45 -0000
Received: (qmail 13413 invoked from network); 1 Jul 2009 22:29:35 -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 s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <fweimer@bfk.de>; 1 Jul 2009 22:29:35 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Thu, 02 Jul 2009 00:29:33 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Florian Weimer <fweimer@bfk.de>
Message-ID: <C671AFED.2EB4%stefan@aaa-sec.com>
Thread-Topic: [TLS] Cached Info extension - Draft 01
Thread-Index: Acn6m2gX/N4KwYyFl0Cy6UxOxo6RKw==
In-Reply-To: <82ws6s27ze.fsf@mid.bfk.de>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Simon Josefsson <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: Wed, 01 Jul 2009 22:29:22 -0000

Because no one has presented a scenario where any attacker could benefit
from a week hash to launch any realistic attack.

The worst thing an attacker can accomplish by tampering with data exchange,
is to cause the handshake to fail, which then, in the worst scenario, will
force the parties to do a new handshake without caching.

Unless the attacker has a way to convince the parties to accept some fake
data that has never been part of a real successful handshake, then the
attacker has no way to capitalize on the fact that a collision is found.


/Stefan


On 09-07-01 9:11 AM, "Florian Weimer" <fweimer@bfk.de> wrote:

> * Stefan Santesson:
> 
>> One difficulty I have is that I don't see, and never have seen, the reason
>> to provide different levels of hash algorithms for a usage that does not
>> require a strong hash.
> 
> Why do you think this doesn't need a strong hash?