Is it possible to perform one-way OTR MITM?

Question

Here's something that is bugging me recently: suppose that me and my friend establish an OTR session and - as a result of that - DH key exchange is performed. My friend verifies my key, but I cannot verify his fingerprint. Despite that, we have a secure channel over which he can send me one bit of information - whether my key was valid or not. Can I trust the OTR session if he successfully verified my key and sent me this confirmation or is there still a risk of a man-in-the-middle attack?

Answer 1

I ended up asking on the OTR's developer mailing list and here's the response I got:

On Wed, Apr 08, 2015 at 02:51:14PM +0200, Jacek Wielemborek wrote:

Hello,

Here's something that keeps bugging me for a moment. It's a hypothetical situation, so please refrain from question like "how did you send the FP to your friend?".

1. My friend receives my OTR fingerprint over a secure channel (e.g. meeting in person), but he doesn't give the fingerprint to me and destroys the channel,

2. Me and my friend establish a perfectly secure channel that has two limitations: my friend can only send messages to me (not the other way) and only one bit of information can be transferred.

3. We agree that over this channel, he will tell me during a future OTR session whether my fingerprint matched what he received from me during step 1,

4. We go back home, establish an OTR session over the internet, which isn't secure yet. My friend verifies my fingerprint based on what we got during step 1 and tells me whether it matched over channel from step 2,

If the fingerprint he sees on the screen matches the thing he got from step 1, can I assume that there can be no man in the middle? In other words, is it possible to perform a one-way OTR MITM where my friend actually sees my real fingerprint, but when he responds, I can't see his, but one from the MITM?

Hopefully I explained this clearly. Cheers, Jacek Wielemborek

Jacek,

Way back in OTRv1, this was actually possible. However, the MITM wouldn't be able to read, write, or modify the messages; the issue was that your buddy would see your key as being the partner in the conversation, while you would see the MITM as being your partner in the conversation. (The messages would actually be going to your true buddy, though.)

We upgraded the key exchange protocol in 2005 to address this problem, and I do not believe a MITM could pull this off with OTRv2 or OTRv3 (unless one of the endpoints were compromised, of course).

[Even better is to exchange a shared secret in your step 1 instead, and then use the SMP to mutually authenticate your long-term keys. But this requires a secure channel in the secrecy sense, whereas your version only requires a secure channel in the authenticity sense; the latter is sometimes easier to pull off in practice.] -- Ian Goldberg Associate Professor and University Research Chair Cheriton School of Computer Science, University of Waterloo Visiting Professor, ESAT/COSIC, KU Leuven