[OTR-users] pidgin, jabber, otr and offline messages

[Paul Wouters]

On Sat, 10 Nov 2007, Michael Reichenbach wrote:

> It seamed I had still an active otr session with my interlocutor. He
> gone offline before and he ended the private conversation.
> OTR Error: You sent encrypted data to jabberid, who
> wasn't expecting it. Many times... All messages lost.

Yes. The bug appears somewhat regularly, but it is very hard to
reproduce, and we haven't caught it yet with a full packet capture to
determine what is going on.

> Next issues, my interlocutor is offline and I want to send him some
> messages he shall read next time he goes online. Each time I write
> something it comes Attempting to start a private conversation...
> jabberid: text... All messages will be also lost.

Yes. OTR requires state and for full functioning interactivity (doing
diffie hellman key exchanges). So either 1) the computer keeps state while
offline or 2) you cannot work offline. The first solution is very dangerous
to support, as "offline" would be the same as "attacker filtering packets",
forcing you to perhaps send all messages with the same one key.

> Otr is working stable and well now if both are online. But if someone
> loses connection, goes offline or is offline it won`t work well.

Yes. It is the price you have to pay.

> We also set to require private messenging and then you can`t even send a
> message if the other one is offline. An important feature got lost
> (offline messages). Isn`t it possible to make otr work also with stored
> messages on the server?

Require private messages requires a handshake between the two parties.
Obviously you cannot do that without the other party being there. See
above.

> I would love to see the offline message support a bit improved.

The only way I can see it, is if support is added for "short term"
symmetric keys, that can be used for a limited period of time to
do "multiple encryption" rounds. This could then be used for other
things too, such as video/audio streams and session keys. Though at
that point, you're getting dangerously close to re-implementing IPsec,
so what I'd really like to see instead, is a "channel binding" of
OTR with IPsec (possible in IKEv2) where you setup an anonymous IPsec
tunnel between the two parties, and through that, do an OTR verification.
This then gives you a "secure end to end tunnel".

The danger of implementing these session keys, is that the policy to
the enduser becomes much more complicated, and you want to protect the
enduser from confusion. Most of them who are not CS students, already
find the three state "not private, "unverified", "private" confusing.

Paul