Difference between revisions of "Thread:Talk:MpOTR/Transport reliability"

(New thread: Transport reliability)
 
m
Line 1: Line 1:
 
Ximin Luo <infinity0@pwned.gg> writes:
 
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
 
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
 
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
+
''
 +
 
 +
I think assuming extra ordinary config/storage/abilities for the
 
server, defeat the purpose of end-to-endness. If some participants are
 
server, defeat the purpose of end-to-endness. If some participants are
 
malicious probably you can't do much bar failing to democratic decisions
 
malicious probably you can't do much bar failing to democratic decisions
Line 22: Line 26:
 
impossible to recover the tree collectively.
 
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
 
All I'm saying using time stamps in contrast to lexicographical ordering
 
required in original mpOTR, makes us able to detect order tampering, in
 
required in original mpOTR, makes us able to detect order tampering, in
 
optimistic way. It wasn't about recovery.
 
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
 
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 and we are restarting consistency check so you all are
Line 34: Line 40:
 
nobody objects).
 
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
 
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
 
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.
 
there is a general consensus that async is off the table for now.

Revision as of 01:14, 3 August 2014

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 think assuming 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.