[OTR-dev] OTR encryption state

[Greg Troxel]

  yes, you're right. while we see it as a problem, i think greg is
  saying that this functionality should be "emulated" by having the user
  set the different modes of operation. so if i wanted to turn
  encryption off, i would just goto mode 1. that's the way i see it
  anyways.

I'm making a distinction between "delete current crypto context" and
"delete current context and go into a mode where you won't try to
negotiate a new one"

To answer Evan,
  IKE : Internet Key Exchange, RFC2409, part of IPsec, RFC2401
     At its core DH with authentiation and algorithm negotiation, but
     fairly complex.

  SA: security association - a combination of the remote parties ID,
  key, cipher type, sequence number, etc.

With IPsec you have a 'security policy database' (SPD) that says what
traffic needs what protection.  On BSD, the kernel sends an ACQUIRE
message to a key management daemon; the daemon then negotiates an SA
and installs it in the kernel, where it can be used by subsequent
packets.

On BSD, IKE is implemented by racoon.  Perhaps on Linux also; there have
been several implementations.  Sometimes racoon gets in a state where
it won't try to get new SAs, typically after the network has been gone
for a while.   I don't want to stop doing IPsec in those cases - my
policy says "this port needs IPsec, period".  So I restart racoon,
which deletes all the SAs and then tries to negotiate on the next
packet because it gets an ACQUIRE.
That's the sense of 'nuke this context' that I'm talking about.

The other action would be "change the SPD so that crypt is no longer
required".