Subject: Re: [IPsec] Quantum Resistance Requirements

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 6 Sep 2016 21:09:50 +0000

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-masked])
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

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

-          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

-          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

-           PPK management; how much support do we provide for automatically managing the secrets?
Scott Fluhrer: not important
Tommy Pauly: 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

-          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

-          Algorithm agility; how important is it that we negotiate any cryptoprimitives involved?
Scott Fluhrer: not important
Tommy Pauly: not important
Valery Smylsov: important

---

From: "Garcia Morchon O, Oscar" <[email-masked]>
Date: Wed, 21 Sep 2016 18:33:09 +0000

Hi Scott,

this is a very interesting approach.
Please, find below my feedback.

Kind regards, Oscar.

From: IPsec [mailto:[email-masked]] On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Tuesday, September 06, 2016 5:10 PM
To: IPsecme WG ([email-masked])
Subject: Re: [IPsec] Quantum Resistance Requirements

From: Scott Fluhrer (sfluhrer)
Sent: Thursday, August 11, 2016 6:01 PM
To: IPsecme WG ([email-masked]<mailto:[email-masked]>)
Subject: Quantum Resistance Requirements

Oscar Garcia-Morchon: very 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.

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.

Oscar Garcia-Morchon: not important at this stage, but it is very important to have hook to easily support this capability in the future.

Oscar Garcia-Morchon: less important, but nice to have and it could be easily supported with little effort.

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.

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Sep 2016 11:14:40 -0400

I would like to weigh in on this point.

> Oscar Garcia-Morchon: this is less important, in particular if we only protect the IPsec traffic.

I think it would be nice to have, but only if the cost is very low.  I prefer disclosure of a key identifier to having to perform a whole series of key derivations until one is successful.

Russ