Hi Scott, thank you for the list of requirements. My answers are inline. In Berlin, we decided to take up Quantum Resistance as a work item, and that we should start talking about requirements. I'm starting this thread in a hope of kicking off the discussion.
First of all, a solution to Quantum Resistance that is applicable everywhere would involve replacing the (EC)DH exchange with a postquantum key exchange. While this would be ideal, the cryptographical community currently doesn't have a solution that is sufficiently trusted and is of reasonable cost. So, it would make sense to divide this into two efforts, a long term solution (which we may initially put on the shelf, as the crypto pieces aren't there yet), and a short term solution, to address the needs of customers that aren't willing to wait; instead, they feel the need to protect traffic that is encrypted now. For this short term solution, it's sufficient if we don't necessarily cover all cases, a number of interesting cases (in particular, ones for which redistributing secrets is doable) would be sufficient. Does everyone agree with that general assessment? If so, there here is a list of potential requirements (based on Tero's list that he gave during the IETF, but with a few of my own), along with my opinion: - Simplicity; how large of a change to IKE (and IKE implementations) are we willing to contemplate? Of course it is preferrable if the solution is simple. However, the simplicity is difficult to measure, so it is mostly subjective. I would put the simplicity closer to the end of the list of requirements. In other words - our goal is to provide a (temporary) QC-resistant solution. If we manage to get it simple - then it's good. 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 properties; how important is it that our solution do not induce any weaknesses in IKE against an adversary with a convention computer; that is, whatever we do, we must not make things worse? This is important. o My opinion: I'm pretty sure that we'll all agree that this is important (except for possibly the identity protection, see below); I just want to state this as something we need to remember. - 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. This requirement is related to the previous one. If we we want to preserve existing IKE properties. then we should provide the solution that protects both IPsec and IKE traffic. And I think it is important that IKE traffic is protected. It will allow to re-use this solution in G-IKEv2 protocol without the need to re-invent it. o My opinion: I'm going to abstain on this one, except to note that protecting only the IPsec traffic allows for a rather simple implementation; now, if the WG decides that protecting the IKE traffic is important, this simplicity is irrelevant. - 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? I think the ID protection is a nice thing to have, but I won't consider it as the first proirity requirement. o My opinion: identity protection in IKE is rather overrated; I suspect there's enough in the data exchange that an advanced adversary (how can look at things such as packet length and packet timings) is likely to get a fairly decent guess regardless. - PPK management; how much support do we provide for automatically managing the secrets? No strong opinion here. o My opinion: we already have preshared keys in IKE, and we don't define any particular management scheme for them (even though they are used quite often in practice). I don't see why we need to go out of our way when it comes to these postquantum secrets. - 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)? Again, no strong opinion here. o My opinion: I'd prefer it if we didn't spend a great deal of time trying to come up with a solution that covers everything. However, if we could include a hook that these schemes could take advantage of (such as an opaque identifier that's passed that has meaning to the PPK manager), that might be reasonable. - 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? It would be nice if authentication is protected also. At least to some extent (by the way, the curent draft seems to achive that, because the SKEYSEED is dependant on the PPK, so any authentication method would be "augmented" by PPK). o My opinion: this draft is here mainly to protect 'store-and-decrypt-later' attacks, and so this attack isn't as large of a concern. On the other hand, we may very well get this for free; if we include our 'post quantum secret' as an input to the KDF, then an active attacker is foiled just like a passive attacker. - Algorithm agility; how important is it that we negotiate any cryptoprimitives involved? I think it is important. I don't buy the argument that the solution is intended to be temporary, so we can sacrifice the algorith agility. As far as I understand the situation with "persistent" solution is currently very moot, so it is unpredictable for how long this "temporary" solution will be in use. Probably it is 1-2 years, probably it is 10-20 years. I definitely don't want to have a 20-year long solution without algorithm agility. o My opinion: this is of lesser importance, as this is a short term solution. On the other hand, I am quite aware that others on this list would disagree with me. Well, here's my list of requirements (and my opinions); did I miss any requirement that you think is important? What are you opinions about these requirements? Thanks! Regards, Valery. ------------------------------------------------------------------------------ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec