[OTR-dev] One-way OTR MITM?

[Ian Goldberg]

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