Hi Scott, this is a very interesting approach. Please, find below my feedback.
Kind regards, Oscar. From: IPsec [mailto:[email protected]] On Behalf Of Scott Fluhrer (sfluhrer) Sent: Tuesday, September 06, 2016 5:10 PM To: IPsecme WG ([email protected]) Subject: Re: [IPsec] Quantum Resistance Requirements Last month, I listed a series of potential requirements for a shortterm Quantum Resistance solution; several people have commented on these requirements, and here are the votes so far (omitting the "no opinion" votes); I've listed the voters chiefly so that if I mischaracterized their votes, they can correct me: From: Scott Fluhrer (sfluhrer) Sent: Thursday, August 11, 2016 6:01 PM To: IPsecme WG ([email protected]<mailto:[email protected]>) Subject: Quantum Resistance Requirements - Simplicity; how large of a change to IKE (and IKE implementations) are we willing to contemplate? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: not as important as other issues Oscar Garcia-Morchon: very important. o My opinion: minimizing changes to IKE should be given high priority, both because "complexity is the enemy of security" and this is a short term solution; if we have a solution that we can't implement in a few years, well, we might as well wait for the crypto people to give us the long term one. - Preserving existing IKE security properties? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: important Oscar Garcia-Morchon: very important. - What do we feel needs to protected from someone with a Quantum Computer? Do we feel the need to protect only the IPsec traffic, or do we need to protect the IKE traffic as well. Tommy Pauly: not clear if IKE traffic needs to be protected. Valery Smylsov: important Oscar Garcia-Morchon: it seems to me that IPsec traffic is the most important one. If IKE traffic could be easily protected as well, this would be a nice addition. - What level of identity protection do we need to provide? If two different IKE negotiations use the same shared secret, do we mind if someone can deduce that? Scott Fluhrer: not important Michael Richardson: very important Tommy Pauly: not important Valery Smylsov: this is a nice to have, but not critical Oscar Garcia-Morchon: this is less important, in particular if we only protect the IPsec traffic. - PPK management; how much support do we provide for automatically managing the secrets? Scott Fluhrer: not important Tommy Pauly: not important Oscar Garcia-Morchon: not important. - How much support do we provide for nonstatic secrets, for example, by QKD, or via something like HIMMO (a key distribution mechanism that appears to be post quantum)? Scott Fluhrer: not important Michael Richardson: not important Tommy Pauly: not important Oscar Garcia-Morchon: not important at this stage, but it is very important to have hook to easily support this capability in the future. - Authentication; if someone with a Quantum Computer can break the DH in real time, do we care if he can act as a man-in-the-middle? Scott Fluhrer: not important Michael Richardson: important, provided that we don't run into the same issues that IKEv1 PSKs ran into Tommy Pauly: not important Valery Smylsov: this would be nice to have Oscar Garcia-Morchon: less important, but nice to have and it could be easily supported with little effort. - Algorithm agility; how important is it that we negotiate any cryptoprimitives involved? Scott Fluhrer: not important Tommy Pauly: not important Valery Smylsov: important Oscar Garcia-Morchon: less important. ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
