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? 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? 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. 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? 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? 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)? 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? 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? 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!
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
