Scott Fluhrer (sfluhrer) writes: > > That is actual real reason to do things differently. I.e. perhaps the KEYMAT > > generation then should be > > > > KEYMAT = prf+(SK_d, g^ir (new) | prf(PPK, Ni) | prf(PPK, Nr)) > > > > instead? > > That would certainly be a more implementable suggestion, if the WG > is OK with the idea that the IKE SAs not being protected. It would > make like living with an HSM easier to deal with, while making the > process of deciding which PPK to use simpler. We may end up > including a simple notification scheme (to help with a brownfield > scenario, where the peer may or may not be upgraded to use PPK yet), > but we might also decide to omit that as well. > > So, is the protection of the IKE SA important? I would personally > vote that it is, but if the WG decides otherwise, then this is > clearly a better proposal.
I agree that having protection of the IKE SA would be nice to have, but I am scared that the complication of deciding which PPK to use will cause issues, and not protecting IKE SA is good compromize, i.e. provides the most important thing (protectiong to the actual IPsec traffic against the QC attacks), while still being so easy to implement and use that everybody can start using it (even the smallest IoT device can do this provided it has PPK somehow available). -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
