Hugo Krawczyk writes: > Why aren't these IKEv1 implementation defending against Bleichenbacher by > hiding the nature of error (decryption error or authentication error) like > what TLS 1.2 does [1]? Is this option documented in any of the IPsec/IKE > documents? Is there a reason why it would not work in IKEv1 as it worked for > TLS?
Mostly as those implementations are old, and have not been touched in last 15 years. IKEv2 obsoleted IKEv1 in 2005, and instead of removing IKEv1 most of the vendors just put IKEv1 on "low maintenance mode", meaning they will fix fatal bugs (crashes etc) but will not do any real development for it. Also when this was big news in TLS few years back, where this "19 year old bug" [1] hits servers again, IKEv2 had already moved on. We had RFC 7427 [2] which allows using RSASSA-PSS and RFC8247 [3] which said RSASSA-PKCS1-v1.5 is no longer recommended. I think there was discussion about this attack in IPsec list 15-20 years ago, but could not find the discussion from my archives now. The IKEv1 uses RSA encryption to encrypt few specific payloads on the exchange, and there is no text in RFC2409 or other places to tell what should you do if the encryption fails, but yes similar thing than what was done for TLS could be done for IKEv1, except IKEv1 is obsoleted, and there is no point of fix issues in obsoleted protocol (I do not think we provide fixes for SSL 3.0 anymore either). I think there is no point of beating the dead horse anymore. I think we should really have the draft-ietf-ipsecme-ikev1-die-die-die-die-die-die-die-die-die-die-die-die-die-00.txt... [1] https://robotattack.org/ [2] https://datatracker.ietf.org/doc/rfc7427/ [3] https://datatracker.ietf.org/doc/rfc8247/ -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
