Hi Scott,

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

Kind regards, Oscar.

From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Scott Fluhrer 
(sfluhrer)
Sent: Tuesday, September 06, 2016 5:10 PM
To: IPsecme WG (ipsec@ietf.org)
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 (ipsec@ietf.org<mailto:ipsec@ietf.org>)
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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to