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
___
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
