[OTR-dev] Fwd: Ensuring transcript soundness in a multiparty chat setting

[Trevor Perrin]

On Fri, Nov 29, 2013 at 3:50 AM, Мария Коростелёва
<maria at korosteleva.com> wrote:
>
> This approach reminds me more about OldBlue [...] What's the
> difference?

Hi Maria,

Good question.  I think I had different assumptions about the
underlying network, and different goals:

 * OldBlue assumes the network is unreliable (can lose, delay, or
reorder any message).

 * OldBlue tries to survive this unreliability via LostMsg and
Retransmit requests, so that messages eventually get delivered to the
higher layer with "causal order", even if this takes awhile and newer
messages get delayed awaiting arrival of lost predecessors.

 * OldBlue doesn't try to detect failures in "timeliness" or
"connectedness" unless these violate causal ordering.  In particular,
these won't be detected:
   (A) Attacker delays all messages you receive for a week.  As long
as the delayed messages eventually arrive in causal order, OldBlue is
happy.
   (B) Attacker "partitions" the group into multiple subgroups, and
doesn't forward messages between subgroups.  As long as messages
within each subgroup arrive in causal order, OldBlue is happy.

I was assuming that a "normal" message stream from any user X to user
Y is ordered, reliable, and timely, and that "good users" broadcast a
message to all other users.

I wasn't trying to build a reliable transport layer, I just wanted
background checking (ideally piggybacked on existing traffic) so any
deviation from above assumptions could be detected as a "security
fault".

(I'm not saying I *achieved* this, I think the (A) and (B) cases need
more thought, but that was the goal).


Trevor