OTR status bar and multiple peer instances

[weinholt]

The OTR status bar can show the green "OTR" text, indicating that the peer is authenticated, even though the peer is not authenticated. To reproduce:

1. Connect three irssi clients to the same server (they should have different .irssi directories). I'll call the clients A, B and C. Add the status bar in client A.
2. Start an OTR session between A and B and authenticate them against each other (e.g. /otr auth foo). Note that /otr contexts on A now lists B as trusted.
3. Change the nick of B to something different and change the nick of C to the nick that B was using. The effect is that A will see B's nick talking with a different DSA key and OTR instance tag. Client B should not finish the OTR session.
4. Have C start an OTR session with A.
5. Client A will see a message that the peer is not authenticated, but the status bar will show the green "OTR" text anyway. /otr contexts will list two entries for the nick that C is now using. One is unverified and the other is verified with SMP.

It might look like this:

11:38 OTR: [ User - Account - Status - Fingerprint - Trust ]
11:38 OTR: > weinholt@localhost - alice - Encrypted -
11:38 OTR:   2DD1DF5E 28B043F6 DA08696F 2F060D18 2C361E5F - Unverified
11:38 OTR: > weinholt@localhost - alice - Encrypted -
11:38 OTR:   76713FCA E7D38481 6C71713B 7AF67A8D 3A583D70 - SMP

(At a few of the steps you'll also need to wait forever for libotr to generate DSA keys.)

It seems wrong that the OTR status bar should show the peer as authenticated when the peer you're actually communicating with is not authenticated.

This was tested with irssi 0.8.15-5 and ibotr5 4.0.0-2 on Debian wheezy amd64 with irssi-otr v1.0.0-alpha1-5-g5f685aa from git.

[dgoulet]

Just to clear things out here, you have three different account names connected to an IRC server (ex: a@localhost, b@localhost and c@localhost) and when renaming one of them after authentication, you still see a "valid" context for the old username ? (which apparently messes up the otr status bar?

Big thanks!

[weinholt]

That's correct, my test used three different account names. But that does not seem to be the essential part of the experiment, it can be done with two account names.

The issue with the status bar may not be as bad as it first appeared. After step 5, messages that client A sends will still use the old trusted context, so the untrusted peer will not be able to read them. The user interface could be clearer on what is actually going on though, but I'm not sure what changes would be appropriate.

I've made an IRC bot that you can verify this issue with, if you like. It's called OTR22 on irc.freenode.net. Start an OTR session against it and trust the first key it uses (0DA17A5B ...). Observe that the bot echoes back anything you send it. Next send the word "swap" (in an encrypted message). The bot will start an OTR session using a different key and instance tag. Observe that the green OTR text is still in the status bar and that the bot no longer echoes back text. This is because irssi-otr is still using the trusted context, but the bot tried to parse the message using its new context. Typing /otr finish will drop that context and you'll see the new untrusted context in the status bar. The bot can now echo back messages again. Write "/notice OTR22 forget" if you want to start the experiment over.

A more pressing UI issue might be that I don't see how one would distinguish between messages from the trusted and the untrusted contexts. Since irssi-otr can have both contexts active (even though it apparently only sends using one context), it can still receive messages from either context, and displays messages from them identically. You can verify this using my bot. Start an OTR session against it and tell it "swap". You now have two OTR contexts active, as before. Write "/notice OTR22 old " to have it send you a message using the old context, and "/notice OTR22 new " to have it use the new context. Note that there is nothing in the UI that would allow you to see if a message came from the trusted context or not.

[weinholt]

GitHub's markdown ate part of my last message. In the last paragraph where it says "/notice OTR22 old ", you can type anything you like after the word old or new.