Re: [TLS] Collisions (Re: Nico's suggestions

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.

/Stefan

On 10-05-13 9:15 AM, "Yoav Nir" <ynir@checkpoint.com> 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: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf of Marsh
> Ray
> Sent: Wednesday, May 12, 2010 5:33 PM
> To: Simon Josefsson
> Cc: Kemp, David P.; tls@ietf.org
> Subject: Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:
> 
> On 5/12/2010 4:30 AM, Simon Josefsson wrote:
>> Marsh Ray <marsh@extendedsubset.com> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls