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

[Trevor Perrin]

On Tue, Dec 3, 2013 at 10:12 AM, George Kadianakis <desnacked at riseup.net> wrote:
>> On Mon, Dec 2, 2013 at 3:43 AM, Ximin Luo <infinity0 at gmx.com> wrote:
>> > On 02/12/13 02:53, Trevor Perrin wrote:
>> [...]
>> >>
>> >> But I agree that committing to DAG predecessors would result in
>> >> smaller messages, so could be advantageous.
>> >>
>> >> OTOH, piggybacking all predecessors means the recipient learns
>> >> all
>> >> predecessors for a message upon receipt of that message.  That
>> >> has
>> >> advantages too:
>> >>
>> >>  * In an OldBlue-type protocol, the recipient could issue LostMsg
>> >> requests for all missing predecessors right away, instead of
>> >> needing
>> >> multiple rounds of waiting for lost messages to arrive before
>> >> discovering more predecessors.
>> >>
>> >
>> > Multiple rounds could be alleviated without resorting to "all
>> > previous
>> > messages", if they communicate their own Frontier in the LostMsg
>> > message. Then,
>> > people handling this LostMsg can infer that the grandparent(s) are
>> > also Lost,
>> > and retransmit those too.
>>
>> That makes sense.  I'll admit I'm not super interested in
>> LostMsg/Retransmit algorithms, as we've got existing chat/messaging
>> protocols that do an adequate job with reliability (I think?)
>>
>
> I'm also not super interested in LostMsg/Retransmit algrorithms. That
> said, I don't think that the current major chat protocols provide
> reliability (when the server is adversarial or when a user suddenly
> disconnects).
>
> For example, I don't think that XMPP provides reliability or
> in-order-delivery on its own (see XEP-0198 and XEP-0184). However,
> because it's used over TCP, its streams are both reliable and
> ordered. Still, communication between Alice and Bob over XMPP actually
> involves two streams: Alice <-> Server and Server <-> Bob.  While each
> of those streams is reliable and ordered, nothing tells us that the
> communication channel Alice <-> Bob is reliable or ordered if we
> consider the server as an adversary (i.e. the server can reorder or
> drop Alice's packets before forwarding them to Bob).

Sure, an adversarial server can do whatever it wants.

But in the "benign server" case, I would hope the XMPP message stream
from Alice to Bob is ordered?  If so, then any ordering violations
could be detected as an attack?


> FWIW, based on https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html, OTR
> itself "assumes a network model which provides in-order delivery of
> messages, but that some messages may not get delivered at all (for
> example, if the user disconnects).". I think OTR provides its own
> reliability by using NAKs and doing retransmissions (at least
> according to section 5.1 of the otr-wpes.pdf paper).

It looks like that's only for handling the case where one party
silently re-starts, and loses the session context.  In that case, she
can request a new handshake, and the other party will re-send the last
message.

Seems like a "best-effort" attempt at handling a common failure case,
but doesn't provide strong guarantees:

"""
In pathological cases, Bob’s message will be lost, but we hope that these
will occur rarely enough that dropping the message will not
impose a great burden on the participants;
"""
https://otr.cypherpunks.ca/otr-wpes.pdf


> Also, IMHO, messages should not be forwarded to the chat client while
> they are in the UNVERIFIED pool. Assuming normal (non-adversarial)
> network operation, receiving message predecessors should be quick and
> users shouldn't even notice the buffering.
>
> We can even make some "Large amount of unverified messages" or
> "Impossible to verify messages from participant X for a while"
> warnings that we can forward to the chat application instead.
>
> (I'm saying this, because forwarding unverified messages to the client
> with a big fat "UNVERIFIED MESSAGE" warning seems like a recipe for
> disaster. Similar to CA-SSL's "The site's security certificate is not
> trusted" usability/security nightmare.)

Yeah, UI is a tough question.  I lean torwards silently forwarding
messages right away, but later raising an alarm if they don't get
verified in some timeframe, but I'm not sure.

We should all pause and read this paper:

http://research.microsoft.com/en-us/people/mickens/thesaddestmoment.pdf


Trevor