Thread:Talk:MpOTR/Transport reliability - Revision history

Vmon at 01:16, 3 August 2014

2014-08-03T01:16:46Z

Vmon at 01:14, 3 August 2014

2014-08-03T01:14:22Z

Vmon: New thread: Transport reliability

2014-08-03T01:12:07Z

New thread: Transport reliability

New page

Ximin Luo <infinity0@pwned.gg> writes:
> the issue is *not* merely a matter of sticking a
> recovery system on top of mpCAT, as you argue below. If you are not
> aware of *how recovery systems work*, then you may end up with a mpCAT
> that does things that it *impossible* to add such a system onto it.
In my opinion mpCAT should be like SSL and IPSEC, the messaging transport control
protocol (MTCP) should act like TCP. The transport protocol should try to build
the message tree you had in mind then a tree can be trun into a global
order which can be passed to mpCat to just affirming the consistency of
the global order. So basically like IP header over TCP header over SSL,
we have "MTCP:blablah:3blah2blah2" then, MTCP will put the ":3blah2blah2"
in correct order then pass it to mpCAT.

> for the end-to-end clients to
> be able to recover from message dropping, the server needs to add its
> own *sequence number* to messages;
I feel think assume extra ordinary config/storage/abilities for the
server, defeat the purpose of end-to-endness. If some participants are
malicious probably you can't do much bar failing to democratic decisions
or admin dictatorship. But under assumption of honesty, it shouldn't be
impossible to recover the tree collectively.

> timestamps are not enough.
All I'm saying using time stamps in contrast to lexicographical ordering
required in original mpOTR, makes us able to detect order tampering, in
optimistic way. It wasn't about recovery.

> if he is told "all future messages may not be consistent".
No by reset, I meant it says some line between message x and y isn't
consistence and we are restarting consistency check so you all are
consistence after message y.". (an easily implementable compromise is to
reset consistency digest at each group key exchange, I'll add that if
nobody objects).

> Perhaps there is some confusion over one of our goals.
>
> One nice goals is to end up with a transport agnostic protocol, that
Again, in my opinion the MTCP should run in a lower layer than mpCat
like TCP, that is how we can be transport agnostic. However, I think
there is a general consensus that async is off the table for now.

@@ Line 1: / Line 1: @@
 Ximin Luo <infinity0@pwned.gg> writes:
-''> the issue is *not* merely a matter of sticking a
+'' the issue is *not* merely a matter of sticking a recovery system on top of mpCAT, as you argue below. If you are not aware of *how recovery systems work*, then you may end up with a mpCAT that does things that it *impossible* to add such a system onto it.''
- recovery system on top of mpCAT, as you argue below. If you are not
- aware of *how recovery systems work*, then you may end up with a mpCAT
- that does things that it *impossible* to add such a system onto it.
 ''
 In my opinion mpCAT should be like SSL and IPSEC, the messaging transport control
@@ Line 15: / Line 11: @@
-''> for the end-to-end clients to
+''> for the end-to-end clients to be able to recover from message dropping, the server needs to add its own *sequence number* to messages;''
- be able to recover from message dropping, the server needs to add its
- own *sequence number* to messages;
 ''
 I think assuming extra ordinary config/storage/abilities for the
@@ Line 40: / Line 33: @@
 nobody objects).
-''> Perhaps there is some confusion over one of our goals.
+''> Perhaps there is some confusion over one of our goals. One nice goals is to end up with a transport agnostic protocol, that''
-−
-> One nice goals is to end up with a transport agnostic protocol, that''
 Again, in my opinion the MTCP should run in a lower layer than mpCat
 like TCP, that is how we can be transport agnostic. However, I think
 there is a general consensus that async is off the table for now.

@@ Line 1: / Line 1: @@
 Ximin Luo <infinity0@pwned.gg> writes:
-> the issue is *not* merely a matter of sticking a
+''> the issue is *not* merely a matter of sticking a
-> recovery system on top of mpCAT, as you argue below. If you are not
+ recovery system on top of mpCAT, as you argue below. If you are not
-> aware of *how recovery systems work*, then you may end up with a mpCAT
+ aware of *how recovery systems work*, then you may end up with a mpCAT
-> that does things that it *impossible* to add such a system onto it.
+ that does things that it *impossible* to add such a system onto it.
 In my opinion mpCAT should be like SSL and IPSEC, the messaging transport control
 protocol (MTCP) should act like TCP. The transport protocol should try to build
@@ Line 13: / Line 15: @@
-> for the end-to-end clients to
+''> for the end-to-end clients to
-> be able to recover from message dropping, the server needs to add its
+ be able to recover from message dropping, the server needs to add its
-> own *sequence number* to messages;
+ own *sequence number* to messages;
-I feel think assume extra ordinary config/storage/abilities for the
+''
 server, defeat the purpose of end-to-endness. If some participants are
 malicious probably you can't do much bar failing to democratic decisions
@@ Line 22: / Line 26: @@
 impossible to recover the tree collectively.
-> timestamps are not enough.
+''> timestamps are not enough.''
 All I'm saying using time stamps in contrast to lexicographical ordering
 required in original mpOTR, makes us able to detect order tampering, in
 optimistic way. It wasn't about recovery.
-> if he is told "all future messages may not be consistent".
+''> if he is told "all future messages may not be consistent".''
 No by reset, I meant it says some line between message x and y isn't
 consistence and we are restarting consistency check so you all are
@@ Line 34: / Line 40: @@
 nobody objects).
-> Perhaps there is some confusion over one of our goals.
+''> Perhaps there is some confusion over one of our goals.
+>
-> One nice goals is to end up with a transport agnostic protocol, that
+> One nice goals is to end up with a transport agnostic protocol, that''
 Again, in my opinion the MTCP should run in a lower layer than mpCat
 like TCP, that is how we can be transport agnostic. However, I think
 there is a general consensus that async is off the table for now.