> On 15 Jan 2016, at 3:55 PM, Valery Smyslov <[email protected]> wrote: > > Hi Yoav, > >>>> 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? >>> >>> 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 initiator cannot validate the cookie - it is an opaque blob for him. > Should he reject > the cookie if its length is more than 64 bytes? Possibly. I don't know. > It's a bit strange to check an opaque object…
It’s an opaque object that the RFC says should be up to 64 bytes. > What about the responder - he doesn't see any cookie in this attack - the > attacker > sends the crafted cookie only to the initiator and sends a crafted > IKE_SA_INIT message w/o cookie to the responder (as far as I understand the > attack). There is a cookie. See Figure 12 in Paul’s blog post: https://securityblog.redhat.com/2016/01/13/the-sloth-attack-and-ikeipsec/ The responder accepts a cookie that it never sent. It doesn’t check the cookie because there is, in fact, no DoS attack. That seems wrong. Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
