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
