Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> wrote: > - 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. Still, I'd like to know what the properties are of the cryptographically long term solution. It seems to me, having read your email and a few of the documents that the long-term solutions are architecturally least disruptive, and the short-term "hacks" are more disruptive. Is this a fair characterisation? Or could we introduce some things now that would make "dropping in" a replacement easier? > - 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. Yes, very 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. > 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. I think it depends upon what the affect on the IKE traffic is. > - 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 think you didn't answer the question you posed. You asked, "different IKE negotiations use the same shared secret, do we mind if someone can deduce that?" which I don't think it strictly about identity protection. I also think that leaking the identity of a mobile end point effectively could be painting a target on them. Consider how much effort is going into IPv6 privacy extensions. > - 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. Yes, I agree. > - 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. I think that this is important, if we can do it without getting into IKEv1 PSK stupids. > - 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? We have to be able to negotiate to use of these extensions. I want to suggest something further: that we might want to negotiate use of some of these extensions as a *rekey* of a "conventional" IKEv2 PARENT. I.e. even the use of these extensions might be too big a red flag. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec