[OTR-dev] Could OTR be made more fault-tolerant?

[Ximin Luo]

On 21/06/15 16:19, Jacek Wielemborek wrote:
> Hi,
> 
> (I'm sorry if this was already brought up - I had no idea which keywords
> to pick when searching for such thread. Also, please CC me while
> answering, I'm not subscribed to the mailing list)
> 
> One of my friends constantly complains about OTR giving him no feedback
> when he sends messages to me while I'm offline over XMPP (Pidgin). Then,
> when I turn on the computer, I have no OTR session currently active and
> all I'm getting is an error message that I got a message that I cannot
> decrypt. This makes me ask him "what have you sent two days ago when I
> was offline" at best and at worst, messages get lost. I'm getting the
> impression that there should be support either from the library or the
> UI to make this easier.
> 
> Another problem that we are constantly getting is that when we try to
> communicate after a few hours of inactivity, it often happens that one
> of us switched between the machines (e.g. by suspending the laptop and
> turning on the PC that also uses the same XMPP address) and the session
> key is no longer valid. To avoid this, I usually manually refresh the
> OTR session whenever significant amount of time passed, but I'm getting
> the impression that I'm walking around a problem inherent to OTR.
> 
> Perhaps there should be some "pinging" mechanism in place or when a
> undecipherable message gets received, an error message should be sent?
> The client could then discard such an error if he keeps a trusted
> session on another channel, basically doing what I'm doing when the
> problem happens. What do you guys think about this?
> 

Hi, Jacek.

Very good points! I don't think there is active work on extending the OTR protocol itself these days. However, I'm working on a secure group messaging protocol aiming for something like multiparty OTR. For this, I've also thought about the things you mention, because these problems get worse in larger groups. Hopefully "real soon now" an early version will be available to test/use on the MEGA chat platform.

The system includes automatic (end-to-end) authenticated acks that people send after a timeout. (The timeout is to help efficiency - if the user was going to write something in response anyway, then this saves a lot of messages.) There is a similar feature in Pond, except that one must trigger it manually [1]. There are some security/usability tradeoffs between the manual/automatic approach, which could do with some research, but is outside of the typical "secure group messaging" goals and threat models - so I haven't spent too much time on it yet myself. Other nice security properties that we achieve (using the same technique as the auto-acks) is the guarantee that no messages were dropped during your session, and that messages are displayed in some sort of topological order, neither of which are guaranteed by OTR.

We do these acks at the cryptographic level; XMPP pings are not useful *from a security point of view* because the transport (i.e. the server or your ISP infrastructure, if the transport isn't even protected) can always send fake unauthenticated acks.

We would also like to add some feature along the lines of an auto-refresh / auto-join when other members leave and rejoin the transport channel, on the assumption that they have lost all previous cryptographic session material, but haven't yet worked out the best way to do this. The technical background on this is here [2], but it builds on top of quite a lot of other material. If you are interested in doing further work in this area, let me know and we can have a more detailed chat about it.

X

[1] https://pond.imperialviolet.org/
[2] https://github.com/infinity0/msg-notes/blob/master/appendix/05-hybrid.rst#corner-cases-caused-by-partial-visibility

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20150621/d293fc17/attachment.pgp>