Paul Wouters writes: > On Mon, 12 Feb 2018, Valery Smyslov wrote: > > >> This is one particular implementation peculiarity, there > >> will be others that behaves oddly. The point is, if we introduce a new > >> Transform Type, it is very likely that backward compatibility can no > >> longer be achieved. > > > > Again, it depends. If the majority of implementations immediately crash > > once they > > receive unknown transform, then I agree that we need another mechanism... > > Most of other cases usually can be dealt with. Probably not all and probably > > not as elegant as we wish, but still I believe they can. > > We still have plenty of time to get the word out to those > implementations to fix their problem. By the time we have a > document ready for post quantum transforms, those implementations > should have been fixed. It's a little early now to deem this > an unsurmountable problem.
Yes. Also there is big difference in requirements for draft-ietf-ipsecme-qr-ikev2 and requirements for proposal doing proper quantum safe algorithms. The draft-ietf-ipsecme-qr-ikev2 is intended to be deployed now, and should work with existing implementations without fatal interoperability errors with them. As quantum safe algorithms itself are so much in ongoing research now, I do not think we will be having implementations out there using any of the quantum safe algorithms now, and so there will be time for broken implementations to get fixes installed to them. I.e., if you still plan on running completely broken strongswan implementation which do not implement MUSTs in IKEv2 for example in year 2019, then you are not interested in security, thus you are not really going to be even try to use anything like quantum safe algorithms to talk to them... I mean, if you plan not to install security updates to your IPsec products for years to come, it does not matter what we do, you most likely have big security holes in your gateways anyways. Even RFC4306 said you "MUST contain exactly one transform of each type included in the proposal" in section 2.7, so what they are doing has never been allowed in the IKEv2. In the RFC5996 we did add text saying: If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual. and if they have not updated IPsec implemenation since 2010, again there will most likely be so many holes in it that there is no point of talking about quantum safe algorithms... We have discussed several times of adding new transform types, and in most cases we have found better ways of doing that. On the other hand there is nothing that would make it impossible to add new transform types. IKEv2 has been designed so that new things can be added without breaking old implementations (provided old implementations actually follow what was written in the IKEv2 RFCs). In this case I think I agree with Valery that adding new transform types might be good option, and we should investigate that option too. > > I prefer to reuse existing code for this and I see no reason why > > it cannot be done. > I agree. Making IKE_SA_INIT more complicated than what is now, is something we do not really want to do. It is first exchange with the peer, it has all kind of denial of service properties which we should try to cope. We do not want to make it so big it will get larger than one kilobyte in size, so it will not get fragmented by the IP layer etc. Doing fragmentation on that layer is very hard if we want to protect that also against DoS. I am very much suprised that some of the vendors really said that they wanted to change the IKE_SA_INIT instead than add new exchange between IKE_SA_INIT and IKE_AUTH. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec