Paul Hoffman writes: > Greetings. We need to update our charter to reflect our current and > expected work. Dave and I propose the following text. Please let us know > within the next week if you have suggestions for changes.
Should we add something about making the IKEv2 resistant to QC based attacks? Btw, looking at the latest attacks against TLS using SSLv2, the IKEv1 parts of the IPsec implementations are starting to scare me. I mean there is lots of old code there, that is not really updated anymore as the IKEv1 is obsoleted, and that code can be used to attack IPsec implementations. We have some customers asking about the DoS attacks IKEv1 using IKEv1 server as packet reflektor, then there is the sloth attack which worked much better against IKEv1 because it used MD5 etc. The problem is that lots of people are still using IKEv1, and there is not really good push away from it. I think it would be good idea to give bit more push to that, i.e., perhaps having draft-ietf-ipsecme-ikev1-diediediediedie (sslv2 and des only needed 3 dies, but IKEv1 is such zombie, that I do not think that killing it 3 times is enough :-) explaining why implementations should not use IKEv1. This is of course will not really change anything, but at least I could use it here in to convince customers that they need to move away from IKEv1, and perhaps it would wake up some implementors who only have IKEv1 in their implementations. Perhaps it could even provide some kind of transition plan: Stop using IKEv1 as default by now, disable automatic fallback by 2017 and require manual configuration to use it, and remove the support of IKEv1 completely from implemenations by 2020. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
