IETF Logo Mail Archive

Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)

Stefan Santesson <stefan@aaa-sec.com> Mon, 10 May 2010 22:52 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 B005B3A6A92 for <tls@core3.amsl.com>; Mon, 10 May 2010 15:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Level:
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, 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 sOLoKnjqktTJ for <tls@core3.amsl.com>; Mon, 10 May 2010 15:52:20 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id 891EF3A695F for <tls@ietf.org>; Mon, 10 May 2010 15:51:58 -0700 (PDT)
Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 56BF528CA6F for <tls@ietf.org>; Tue, 11 May 2010 00:51:55 +0200 (CEST)
Received: (qmail 43245 invoked from network); 10 May 2010 22:51:46 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.16]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <simon@josefsson.org>; 10 May 2010 22:51:46 -0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Tue, 11 May 2010 00:51:44 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Simon Josefsson <simon@josefsson.org>, Nicolas Williams <Nicolas.Williams@oracle.com>
Message-ID: <C80E5AA0.AB38%stefan@aaa-sec.com>
Thread-Topic: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)
Thread-Index: Acrwk1y5OlnF4kMyZk6FdjhbkjPMjA==
In-Reply-To: <87bpcn4cy6.fsf@mocca.josefsson.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)
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, 10 May 2010 22:52:20 -0000

On 10-05-11 12:19 AM, "Simon Josefsson" <simon@josefsson.org> wrote:

> (different from what the real server would send), fail the
> handshake, and let the client re-try against the real server, and the
> client would then use the wrong cached information.


And.... ?

I don't mean to be rude, I just want you to complete the threat scenario.

In what way may this serve the attacker?
In what way may this cause serious harm to the victim?

If the client is fooled to cache the wrong server certificate, key
establishment will fail.

If the client is fooled to believe in a false set of acceptable CA names,
then the client may fail to find an acceptable client certificate to use.

Both will cause the handshake to fail (and cause next attempt to be without
caching).


/Stefan

v2.23.0 | Report a Bug | By Email