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

[Trevor Perrin]

On Thu, Nov 21, 2013 at 3:47 PM, George Kadianakis <desnacked at riseup.net> wrote:
> Trevor Perrin <trevp at trevp.net> writes:
>
> Because your "consensus check" format contains the number of messages
> contributed by each participant, a receiver knows when the "consensus
> check" of a message is incomplete and can instead calculate the digest
> for that specific subset of messages.

I was thinking of something a bit different: if a message X is
received before its "causal predecessor" messages, the recipient would
set a timer and expect the predecessors to arrive before the timer
expires; once the predecessors arrive, X's consensus hash is verified.

Not sure whether X should be displayed right away, or only after its
predecessors arrive (like Old Blue)?  I guess that's more of a UI
question.


> This seems like it might work. But we should still consider some
> scenarios:
>
> - What happens if an evil participant selectively sends a message to
>   n-1 participants? That is, all participants but one.
>
>   If this happens, the n-1 participants will start including that
>   extra message in their consesus check, but the single participant
>   who was left out will not be able to calculate a proper digest.
>
>   But I guess that's why you included the timestamp in the consesus
>   check [0]: So that after a while (when the missing message can't be
>   attributed to network latency) the client of the left out
>   participant will be like "hm, something weird is happening with your
>   transcript!".

I think a timestamp isn't required for that, only local timers.  Once
the victim recipient learns of the existence of an "extra message"
from any other participant, the victim will set a timer, and expect
the extra message to arrive before it expires.

The timestamp would help a silent (non-broadcasting) victim realize
that everything she's seeing is causally consistent but, say, delayed
1 week.

But if the victim were to broadcast periodic, empty ACK messages with
consensus checks, you could maybe achieve that without timestamps.
The other participants would immediately realize the victim was
(unacceptably) far behind by looking at her consensus check, *or* - if
the victim's ACK was dropped - the victim would observe the other
participants fail to include her ACK within an acceptable time.


> - What happens if the consensus check fails? You said "then this is a
>   security error, and the chat is shut down." but shutting down the
>   chat so easily might enable DoS attacks that can be triggered by a
>   single evil client who sends corrupted consensus digests

Hmm, I *think* it wouldn't be that hard to report that "User A is
reporting a different view of the chat from B,C,D,E".  You could
restart the chat, but if that happens repeatedly, you exclude User A?

Another problem is that I'm assuming message streams are ordered *and*
reliable.  I believe OTR traditionally has assumed ordered but not
reliable streams.  Do typical OTR-supporting chat protocols drop
messages often?

If you have to deal with unreliable message delivery, I think you
either need some sort of ack / retransmit layer, or some more
complicated consensus algorithm...


Trevor