> On 15 Jan 2016, at 10:55 AM, Yaron Sheffer <[email protected]> wrote: > > However, thank you for bringing in the SLOTH attack. >> As fas as I understand from the paper >> http://www.mitls.org/downloads/transcript-collisions.pdf it is based on the >> ability for an attacker to find collisions in a weak hashes (md5 and sha1). >> In particular the authors uses chosen-prefix collision attacks >> to break some security protocols. They mostly focused on breaking TLS, >> but Section VI contains description of a possible attack on IKEv2. >> >> As far as I understnd the attack on IKEv2 it is based on the cookie request >> feature. The attacker makes a cookie request to the initiator >> with the cookie crafted in such a way, that the hash of the IKE_SA_INIT >> message >> containing this cookie would collide with the hash of the IKE_SA_INIT message >> containing attacker-chosen KE payload. It would allow the attacker >> to impersonate the initiator. >> >> If I got it right the ability for an attacker to quickly find a hash >> collision >> is based (besides using weak hashes) on presumption that the cookie is >> always the very first payload in the message, >> as depicted in the Section 2.6 in the RFC 7296. So it is >> presumed that the cookie always preceedes any unpredictable >> for the attacker values in the message, that allows to perform >> an effective chosen-prefix attack on a hash. >> >> So, I think that we can completely thwart this attack (regardless >> on the possible weakness of the used hashes) if we make >> a recommendation for implementers to put the cookie at the >> end of the message. RFC 7296 doesn't imply any restrictions >> on the payloads order. However the Section 2.6 states: >> >> If the IKE_SA_INIT response >> includes the COOKIE notification, the initiator MUST then retry the >> IKE_SA_INIT request, and include the COOKIE notification containing >> the received data as the first payload, and all other payloads >> unchanged. >> It's a bit unclear for me whether this MUST is concerned with the >> requirement to retry request only, in which case it is only >> a recommendation to place the COOKIE before other payloads, >> or the MUST is also applied to the text that COOKIE is the first payload >> (that would be unfortunate). >> >> What does IPsec community think of it? Should we fix the protocol >> to thwart this attack completely? Is the recommendation to move the COOKIE >> to the end of the message enough to achive that? >> Will this change break many existing implementations? >> >> Regards, >> Valery Smyslov. > > As far as I can tell, the cookie hash algorithm is an implementation decision > of the responder and (despite what's implied in the paper) is never specified > in the protocol. It would be much simpler to add a section to the new 4307bis > saying that this hash is security-critical, and recommending SHA-256 or > stronger.
The SLOTH paper does not depend at all on the hash used to break the cookie. They use the cookie mechanism to inject a prefix (Because the Initiator dutifully repeats the cookie that the MITM gave them) to control the hash of the entire packet to create a collision. They also rely on neither Initiator nor responder checking cookie lengths or even validating the cookies if a DoS attack is not underway. Maybe we should specify that in the anti-ddos draft. > The experience with TLS is that making small protocol changes to protect > against weak algorithms is not a good long-term strategy. It's just a > challenge for researchers to come up with better attacks. > > I believe the hash-and-URL mechanism is not used in practice. But if it is, > that's another place where we have hardcoded SHA-1, and maybe we should start > worrying about it. AFAIK a second pre-image attack on SHA-1 where the second pre-image looks like a valid X509 certificate is still far. Even if it were not, what is the attack? the real Initiator fetches the wrong certificate and the authentication fails? This happens even if you don’t match the SHA-1. Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
