Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:

Stefan Santesson <> Thu, 13 May 2010 08:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3778C3A6B7E for <>; Thu, 13 May 2010 01:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.655
X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BgMyCXMuZGsB for <>; Thu, 13 May 2010 01:01:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2BCDA3A6B9A for <>; Thu, 13 May 2010 01:01:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BF28937AC3E for <>; Thu, 13 May 2010 10:00:59 +0200 (CEST)
Received: (qmail 41120 invoked from network); 13 May 2010 08:00:56 -0000
Received: from (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <>; 13 May 2010 08:00:56 -0000
User-Agent: Microsoft-Entourage/
Date: Thu, 13 May 2010 08:00:53 +0200
From: Stefan Santesson <>
To: Yoav Nir <>, 'Marsh Ray' <>, Simon Josefsson <>
Message-ID: <>
Thread-Topic: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:
Thread-Index: Acrx4kge2BcBmY74R7+Kap33WvFRwwAh/jWwAAIJ71o=
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: "Kemp, David P." <>, "" <>
Subject: Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 May 2010 08:01:44 -0000

Very well put.
This is my thinking as well.

For the sake of completeness there is also the scenario:

- It can hijack the connection as a MITM and try to replace the list of
acceptable CAs to the client with another which somehow has a colliding
hash. This will however lead to handshake failure since finished calculation
will fail and nothing will be cached. Fail.


On 10-05-13 9:15 AM, "Yoav Nir" <> wrote:

> I kind of fail to see where the discussion shifted. In fact we have NOT
> determined that *malicious* collision resistance is a concern.
> A client connects to a server and caches the credentials. Next time it
> connects to the *same* server, it shows an extension that proves knowledge of
> the credentials. Assuming the credentials haven't changed, the server can skip
> sending the credentials, but still has to prove ownership by signing something
> or by decrypting the pre-master secret. So what could an attacker do?
> - It can hijack the connection, and not accept the cached credentials, but
> then it would need to present credentials of its own. Fail.
> - It can hijack the connection, and accept the cached credentials, but
> assuming it doesn't have the same public/private key pair, it will then not be
> able to sign or decrypt. If it does have the same public/private key pair, it
> could use the legitimate server's credentials anyway. Fail again.
> - It could get the client to connect to his malicious server first. In some
> magical way he has acceptable credentials, which the client caches. What
> happens next is not relevant, because the attacker has already won, but for
> the sake of argument, let's go on. The next time, the client connects to the
> legitimate server. It tries to use the cached credentials, which somehow
> collide with the attackers' even though the public key is different (I don't
> think we could attack even CRC this way). So the legitimate server accepts the
> cached credentials, but the handshake fails, and the client clears the cache.
> The third thing seems to succeed, but it depends on being able to predict a CA
> signature to such an extent, that you can make two certificates with a
> different public key collide in FNV, and it depends on being able to at least
> once dupe the client into thinking your server is the legitimate one. And all
> you get is a one-time DoS.
> OK. So where's the real attack?
> -----Original Message-----
> From: [] On Behalf of Marsh
> Ray
> Sent: Wednesday, May 12, 2010 5:33 PM
> To: Simon Josefsson
> Cc: Kemp, David P.;
> Subject: Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:
> On 5/12/2010 4:30 AM, Simon Josefsson wrote:
>> Marsh Ray <> writes:
>>> Alternatively, if we determine that indeed the non-collision-resistance
>>> of the hash function is the root of all remaining concerns that would be
>>> very positive. We could solve them all in one stroke with
>>> s/FNV-1a/SHA-256/g.
>> If collision-resistance is a required property (I'm not convinced yet),
>> I believe we need hash agility for the possibility that SHA-256 is weak.
> But perhaps that agility already exists in the form of the protocol
> version negotiation.
> TLS 1.2 appears to effectively depend on SHA-256 (at least in HMAC form)
> for the PRF. If that gets broken, we can probably not trust anything
> else negotiated in the handshake and a rev of the base protocol will be
> required to fix it anyway.
> If bare SHA-256 is a concern, the hash could be defined as something
> like hmac_sha256("Cached Info", object_bytes).
> Just a thought.
> - Marsh
> _______________________________________________
> TLS mailing list