Hi Scott, Great list! Responses inline.
Best, Tommy > On Aug 11, 2016, at 3:00 PM, Scott Fluhrer (sfluhrer) <[email protected]> > wrote: > > 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. Simplicity is definitely crucial to whatever solution we choose, and I think the current proposal of a pre shared key that gets mixed into the crypto is the simplest option we have now without really knowing what true QR algorithms will entail for IKE. > - 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. Definitely 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. > 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. My first reaction would be to focus on the IPSec traffic, which is clearly important. It's not clear yet if IKE being protected is useful; exactly how much more complicated will the exchange be, and is it worth it? > - 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. I agree that the aspect of identity protection is already a bit of a lost cause for this, and the new key will not significantly worsen the situation. > - 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. The management seems like a separate issue for deployments to figure out. I can imagine guidelines being published later, but let's just get the crypto spec out first. > - 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… I generally agree with Scott on these points. > > 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec>
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
