[OTR-dev] OTR encryption state

[Greg Troxel]

> From: Paul Wouters <paul at cypherpunks.ca>
> 
> On Thu, 27 Jan 2005, Greg Troxel wrote:
> 
> > I don't see why 'discard context' shouldn't send an authenticated
> > message to the other side saying that, similar to an IKE Delete notify
> > message.
> 
> Actually, there are problems involved with that approach. What if that
> happens to be the packet you miss due to packet loss (or an active attacker).
> IKE solves this by always allowing a renegotiation of IKE in plaintext from
> the IP it has an ISAKMP SA for. Unfortunately, we don't have that in OTR,
> since we are re-using the only channel we have between the two parties.

Sure, a delete can be missed.  It just aids cleanliness most of the
time, and enables the remote side, when it works, to negotiate a new
SA before the old one times out.

Isn't the channel subchannelized by tags at the beginning?  (or
shouldn't it be?)

> Yes, but again, you have the luxury of being able to communicate both
> encrypted and plaintext to the same machine (where for plaintext only IKE
> messages are accepted).

I really don't see why one couldn't send a KEX message instead of an
encrypted data message.  Certainly a restart at one end will need this
to recover, since effectively in OTR all delete messages are lost
(since they aren't sent).

> In fact, Openswan gives you additional protection here with the uniqueids=
> option, which you can use to decide whether or not to ignore these new
> plaintext IKE packets or not. If you decide to ignore them (eg to twart
> spoofed IKE packets interfering with your established ISAKMP connection)
> you also condemning yourself when you or your remote partner crashes or
> receives a new IP address. You will have to wait the remainder of the SA
> keylife before you can negotiate a new SA. Needless to say, uniqueids=
> is on per default, meaning that if a known party appears on a new IP or
> suddenly starts sending new plaintext IKE packets, you allow these packets
> and when you have a new SA, you kill the old one.

Sure, but calling the IKE messages 'plaintext' is not quite fair,
since to complete an IKE exchange one has to create a signature.

> Assuming th epacket makes it. You'll be suprised how often Notify
> Delete's get lost, especially on roadwarrior type setups. (or worse,
> someone losing their access point or just closing the lid on their
> laptop, causing no Delete/Notify message to be sent at all).

Sure, I'm mostly talking LAN environment, using transport mode for
filesystem traffic.

> The real potential information leak is at the restarted client. That user
> might accidently send a cleartext message, forgetting his client or
> connection got restarted.

Exactly.  This is why I suggested having a 'require' state bit per
peer, much like an Ipsec SPD.

> One way to resolve this would be to initiate OTR
> for all buddies you had an OTR connect with when shutting down that are
> currently listed as online, but I fear that would only add to the amount
> of fingerprint windows I need to click away in the morning that I already
> have.

That would also send a lot of KM traffic when there was no data
traffic.

Do you have any objections to a per-user 'require' bit?