Hi, Stephen
> On 30 Aug 2016, at 4:38 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > I have a suggestion about this bit of work: > > "IKEv1 using shared secret authentication was partially resistance to > quantum computers. IKEv2 removed this feature to make the protocol > more usable. The working group will add a mode to IKEv2 or otherwise > modify IKEv2 to have similar quantum resistant properties than IKEv1 > had." > > My suggestion is twofold: > > 1) - s/will add/will consider adding/ > > and to add to the end: > > 2) "In doing this work the WG will consider ongoing work on > quantum-resistance > in the CFRG, and whether it is better to re-instate the same level of > resistance > that was present in IKEv1 or to wait for more recent work (e.g. in CFRG) > to > mature." > > The reason I suggest this is that it's possible the WG might conclude > that > it's better to wait for some newer QR stuff from CFRG. The current > wording > seems to commit the WG to firing ahead anyway, and we might overall be > better if there are fewer QR mechanisms proposed, rather than adding > some > now when it might be better to wait a while longer. There is a reason for this language. Obviously what this item suggests is not the solution to the QC-equipped adversary that we are looking for. But the good solution is not likely to surface any time soon. In the meantime we are hearing that some deployments are reverting to IKEv1 because of its perceived better quantum resistance. IKEv1 has been deprecated for over ten years. In addition to some objective shortfalls, IKEv1 has been considered a legacy feature for many implementers. For an anecdote, we never bothered to implement IPv6 support in IKEv1. The prospect of a user demanding not to have to choose between IPv6 and quantum resistance is not something I look forward to. This is the motivation behind this item. If we were looking for the good solution this item should probably have been phrased as “the WG will follow research into quantum resistant algorithms for authentication and key exchange and consider their suitability to IKE”, because I don’t think we’re going to have something concrete in the next 3-5 years. Fixing this to make it no worse than IKEv1 (not aiming very high, I guess) is doable in months. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
