[OTR-dev] Draft of Security Analysis

[Andrew S. Morrison]

Thanks for the reply. I have a few clarifications that we'll put in the
paper before it's final version, but should help aide discussion now.

> 3.1 Version Rollback
>
>     Version rollback, I think, is only a serious concern when it's
>     invisible (in SSL, for example).  In OTR (at least the gaim-otr UI;
>     I can't speak for the others), it's clear when you're sending and
>     receiving encrypted messages, and when you're not.  Additionally,
>     it's made clear when you're using version 1 of the protocol, so you
>     can take the precaution of asking your buddy to say her name.

Although it's possible to set which versions you will and will not use in
the UI, setting it to "any version" or "just 1 or 2" allows an attacker to
force version 1 or 0 even if 2 is the desired version for both
parties. So, although the conversation will be encrypted and it may be
clear to the user that they're using version 1 instead of the version 2
that they desired, they will accept this thinking that the other party
only supports vesion 1.

> 3.2 Attack on Strong Deniability
>
>     The attack relies on Bob publishing incorrect MAC keys.  But that
>     doesn't make sense; Bob publishes the MAC keys in order *to protect
>     himself*.  Intentionally publishing incorrect ones (or, he may as
>     well just not publish them at all) would only serve to weaken his
>     own deniability.  Note also that Alice and Bob each publish the MAC
>     keys, so they'd *both* have to be intentionally trying to make their
>     own conversation not deniable.

I think the point is that an attacker with tight network control on both
end points is capable of removing or mangling the published MAC keys, and
thus destroying strong deniability.

> 3.3 Message Integrity
>
>     Good call on this one.  Bizarrely, it doesn't turn out to be a
>     security hole in the deployed software because there's a bug in
>it. (!)
>     The deployed software only publishes MAC keys that were used to
>     receive messages, not ones on messages it sent.  This is safe,
>     because it knows for sure that it'll never trust a MAC key that it's
>     already published.  I also believe that even if Bob is cheating, and
>     doesn't publish any MAC keys, but only Alice publishes the MAC keys
>     of the messages she receives, they still get strong deniability:
>     Mallory can take one of the messages Alice received (and
>     subsequently published the MAC key for), and substitute a g^y of his
>     choosing.  He can then recompute the keys and MACs for future
>     messages in the transcript.  [It's late, and I'm doing this quickly,
>     so I don't guarantee this is correct.  I'll think about it some more
>     in the next couple of days.]  Assuming this is correct, you indeed
>     found a problem with the spec, but not in the implementation,
>     because the implementation turns out to be more secure than the
>     spec.

I knew bugs would start pulling their own weight one of these days :)

I think it's an error to be trusting only a single party to publish the
MAC keys. That gives a single party the power to enable or disable strong
deniability for half the conversation. This is weaker security than is
claimed.

> 3.4 Authentication Failure
>
>     I don't see the problem here.  Alice believes she's talking to Bob,
>     because she *is* talking to Bob.  If Mallory is passing messages
>     through unmodified, she may as well be a wire.  It's not a security
>     problem if Mallory sees encrypted messages, and her being able to
>     stop Alice and Bob from talking to each other is just a Denial of
>     Service attack, which we explicitly don't care about.

This attack is a bit of an edge case, but we believe it's a valid attack
on the protocol nonetheless. The point is that one party is committing to
the AKE having no clue who they're talking to. Bob doesn't know who Alice
is and has no desire to communicate with her, but still she is able to be
convinced to commit to AKE with him. Perhaps the invariant that "no party
shall commit to an AKE exchange without both parties being who they say
they are" is too strong.

I think the real "edge case" part about this attack is that there is
nowhere interesting to go once Alice has been tricked.



-- 
Andrew S. Morrison
asm at cs.stanford.edu
(650) 575 9261
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20060307/22e2fbd7/attachment.pgp>