Scott Fluhrer (sfluhrer) writes: > > Or could we introduce some things now that would make "dropping in" a > > replacement easier? > > Nothing comes to mind; according to the above wild speculation, the > difficulties that people are likely to encounter are more to do with > the implementations, and less with the protocol. > > Actually, there are some interesting postquantum protocols (e.g. > McEliece) which look good, except that they have massively large key > shares. I've considered them impractical; however if there was > something easy we could do to make those more practical, that may > help. I'm not suggesting that we do; you just asked if there was > anything we might do that would help...
Combining those two above, i.e., some postquantum protocols require too big packets so they are not usable in IKE context directly, but they do generate out some kind of shared secret which can be used to derive keys, we might implement our drop in postquantum protcols in way where the postquantum protocol is run outside the IKE context, and it just generates the shared secret to be used in the IKE. I.e., now we have shared PPK configured in and used in the KDF. After postquantum protocols are there, instead of having preconfigured shared PPK, we first run the postquantum protocol over some other channel (over tcp? or something, if it requires big packets etc), and the output of that process is the shared PPK we can use for IKE, just like our short term solution uses. I.e., if the postquantum protocols are going to be something that mimics Diffie-Hellman in away that they provide some shared secret we can mix in to KDF then we should be able to use that output with our short term PPK solution too. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
