On 03/08/2011 12:45 PM, Martin Rex wrote:
RFC-5746 TLS extension Renegotiation indication
Yes, it would be bad if those could be collided.
I'm sorry, but I think it is a bad idea to use a flawed design for
the TLS finished message by subverting the collision resistence
of stronger secure hash functions that are used for the PRF.
Here's how my reasoning goes. I could be wrong.
The Finished.verify_data represents a 96-bit MAC, not a general-purpose
cryptographic hash function.
The attacker is presumed to have the ability to modify data at some
points in the protocol stream. The protocol relies on correct
validiation of the verify_data to detect this condition and abort.
Master_secret is not known to the attacker, if the connection is
properly authenticated. The authentication only depends on the
verify_data to prevent downgrade attacks. But if the authentication is
broken, the attacker can simply issue the proper MAC and has no need to
collide them.
Master_secret is very long, changes every full handshake, and is
required to compute the MAC.
Any offline precomputation the attacker could do in support of collision
finding requires the ability to compute the MAC function for the actual
master_secret (as computed by the client or the server including
locally-generated entropy not received from the attacker).
Therefore, collisions on the Finshed.verify_data require active sessions
to be useful and the attacker will need to amass a pool of about 2^48 of
them to collide between.
- Marsh
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf