RE: SOI QUESTIONS: 2.4-2.6

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

> 2.4.A) JFK requires substantially more cryptographic operations for
> rekeying (two more signatures, two more signature validations, and
> three more hashes).  Is this a problem?  More generally, does SOI need
> to be able to support "fast" rekeying?

I think fast rekeying is a good thing, but the more important consideration
is the case where we need to have multiple SAs between two peers (e.g. QoS).
There is a kludge to speed this up in JFK (cache the DH and the cert
verification), but you still have to do one extra RSA signature+validation.
Also, it is a kludge, and kludges hardly simplify the protocol.

There is also the case of dynamic selectors where you need to either create
a new SA or (better) update the selectors on an existing SA. This is much
faster if you already have a control channel.

Finally, let us not ignore MSec. That WG has based their GDOI protocol on
IKEv1, presumably with the assumption that they could migrate seamlessly to
SOI. There is a high probability that many of the same devices which
currently do IKE will also want to do GDOI, so it doesn't make sense to
divorce the two. MSec is likely to require much more frequent rekeying than
SOI, and the rekeying may be based on LKH, in which case doing an extra DH
would be a complete waste of time. Fast rekeying is a MUST for MSec.


> 2.5)  Plausible denaibility

I think plausible deniability is a "nice to have," but not a requirement.
There might be some cases where you would want NR instead. However,
plausible deniability appears to be easy to include in all the cryptographic
cores we have seen, so I think we should do it.


> 2.6.)  Does SOI need to provide a formal proof of security?  (Is this
> a "must have" or a "nice to have"?  What are we willing to trade-off
> for having a formal proof of security?)

I think formal proofs of security are highly overrated. The formal proof in
JFK is basically just a bunch of hand-waving and appeals to cryptographic
common knowledge. In reality, we can be confident in the base security of
the protocols because the cryptographic cores use well-established
techniques.

The problem with formal analyses is that you only find the problems you are
looking for. What happens when the problem turns out to be something
unexpected (e.g. you hadn't considered DoS attacks).

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.