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

Simon Josefsson <simon@josefsson.org> Tue, 11 May 2010 08:03 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 D30203A6B1D for <tls@core3.amsl.com>; Tue, 11 May 2010 01:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.365
X-Spam-Level:
X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 SxbXoJYoA0fR for <tls@core3.amsl.com>; Tue, 11 May 2010 01:03:19 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 2A3A73A6B1B for <tls@ietf.org>; Tue, 11 May 2010 01:00:14 -0700 (PDT)
Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4B7xpDr029220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 May 2010 09:59:55 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Stefan Santesson <stefan@aaa-sec.com>
References: <87bpcn4cy6.fsf@mocca.josefsson.org> <C80E5AA0.AB38%stefan@aaa-sec.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100511:stefan@aaa-sec.com::bWm/MkZbLhUtsM3B:jo+
X-Hashcash: 1:22:100511:tls@ietf.org::TZkh5xRDfbH5QCcl:5y8W
X-Hashcash: 1:22:100511:nicolas.williams@oracle.com::dCi9CaoW+CfZohBF:5721
Date: Tue, 11 May 2010 09:59:51 +0200
In-Reply-To: <C80E5AA0.AB38%stefan@aaa-sec.com> (Stefan Santesson's message of "Tue, 11 May 2010 00:51:44 +0200")
Message-ID: <87bpcm3m2w.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.96 at yxa-v
X-Virus-Status: Clean
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: Tue, 11 May 2010 08:03:20 -0000

Stefan Santesson <stefan@aaa-sec.com> writes:

> 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).

I'm thinking about two scenarios:

 1) the undetectable modification of the list of acceptable CA names
    cause the client to select and use an unintended certificate.

 2) where multiple server certificates can be used to successfully
    establish the key.  That can happen if two certificates use the same
    public key.  Once connected, the client will not know the server by
    the same identity (certificate) as the server believe the client
    used.

This is not an problem in the sense that an attacker gains some benefit
(for 1 the client chose to proceed with the certificate and for 2 the
attacker needs to know the private key of the server): instead I'm
pointing at a semantic problem because, with the extension, the
historically true invariant that the client, after handshake, will know
which certificate the server used, does not hold strongly.

This doesn't necessarily have to affect the document in any way, but it
is an interesting property.

/Simon