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

[Yoav Nir <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf of Marsh Ray
Sent: Wednesday, May 12, 2010 5:33 PM
To: Simon Josefsson
Cc: Kemp, David P.; [e-mail]
Subject: Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:

On 5/12/2010 4:30 AM, Simon Josefsson wrote:
> Marsh Ray <[e-mail]> 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