[OTR-dev] Security guarantee of OTR AKE

[U.Mutlu]

Nick Guenther wrote on 12/11/2015 10:09 PM:
> On December 11, 2015 1:19:20 AM EST, "U.Mutlu" wrote:
>>
>> So, my question is: does OTR protect against impersonation and MITM in
>> the AKE phase? Or is it a TOFU protocol like SSH?
>>
>
> This is what the "verify" steps are for. You trade a secret key with
> someone and ask them to enter it, or you ask them a question only they
> could know. That's the idea, at least. In practice I've found that these
> options are unusable, because in the second your partner needs to spell
> their answer exactly as you intended and they always miss a capital or a
> period, and in the first you need an out of band channel or to meet up
> first.
>
> The third verification option, just accepting blindly, makes OTR a TOFU
> protocol.  This is what I do most of the time, even when my friends'
> clients change (and now you all know to MITM me, I guess).  Or, if you do
> meet up in person, you can just verify fingerprints instead of trading a
> key to verify later. Xabber even lets you trade fingerprints via QR code.

Hmm. too bad, I was hoping to have finally found a truely secure protocol with 
OTR.

Then, IMO one could have designed OTR much simpler since all the unnessary
overhead beyond DHE in the AKE phase brings, as shown, no additional
security against impersonation and MITM.
I mean the role of the SIGMA protocol in OTR AKE seems questionable,
because one can ask: what additional security or safety does it add at all
if impersonation and MITM is still possible?

Additionally, I think also the SMP part in OTR is IMO not really neccessary at 
all,
because instead of it one could have hashed some shared secrets from
the AKE phase right into the MAC(s).

I mean, I just wonder why after creating a secure channel one still needs
to protect with SMP against impersonation and MITM; instead MAC(H(...)) should 
be sufficient IMO.


-- 
U.Mutlu