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

Marsh Ray <> Tue, 11 May 2010 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E85B63A69A1 for <>; Tue, 11 May 2010 15:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.519
X-Spam-Status: No, score=-0.519 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_40=-0.185]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kLQIkdxDC6nV for <>; Tue, 11 May 2010 15:55:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 073E93A6853 for <>; Tue, 11 May 2010 15:55:51 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1OByMX-000KpA-3w; Tue, 11 May 2010 22:55:41 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 52635631D; Tue, 11 May 2010 22:55:37 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1/mPjMZHBrsi7i3jScuzUFEXYPjaVVUXm4=
Message-ID: <>
Date: Tue, 11 May 2010 17:55:39 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Stefan Santesson <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson <>,
Subject: Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)
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: Tue, 11 May 2010 22:55:53 -0000

On 5/11/2010 4:15 PM, Stefan Santesson wrote:
> On 10-05-11 11:30 PM, "Marsh Ray" <> wrote:
>> 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.
> I'm not convinced this is required, but I could live with it.
> I would hate to have to add agility and hash negotiation though.

I agree that negotiation of the hash function would be (to put it
mildly) somewhat less than ideal. Really, a successful use of cached
info has only got one shot to work (server hello, client hello).
Negotiating the algorithm at the same time as negotiating the hashed
values sounds like a lot to expect!

If a cryptographically strong hash function turns out to be required, it
ought to follow TLS-1.2's lead and be defined as SHA-256.

On 5/11/2010 4:00 PM, Stefan Santesson wrote:
> Nico,
> For there to exist two server certificates with the same public key but
> entirely different certificate data, which are crafted to create a hash
> collision, you must have at least one bad certificate issued by a dishonest
> CA who validates to a root trusted by the client.

Keep in mind that some implementations don't actually start validating
the cert chain until the Finished message is received. There's some
logic to this: it hasn't really been proven to have not been "adjusted"
by an attacker until that point anyway and there are good reasons to not
give away precisely at what point the handshake was considered to be a
failure. In practice, it's probably more of a "fits with existing
architecture" decision though.

> If this is the case, then cached info is the least of your problems.

Which is not to say it's not a problem or could never happen.

> For example, you have real problems if that same bad CA issues the attacker
> a certificate (with the same name but another public key) through which the
> attacker (having the corresponding private key) actually can fool the client
> to authenticate the attacker as the legitimate server.

What about if the private key were leaked and the cert was subsequently

Does this extend then to fully checking against CRLs?

Could oddball types of certs (PSK, static DH, etc) work any differently
in this regard?

Just tossing out questions.

> On the other hand, I would not object to include a requirement that data
> should/must only be cached from a successful handshake where the server is
> successfully authenticated. That should remove any residue of this issue.

If "successfully authenticated" is only fully determined sometime after
returning application code, does that mean that this extension should
never come enabled by default for a TLS library?

- Marsh