View source for Talk:MpOTR/Overview
This is a threaded discussion list to collate all discourse on protocol creation, adversarial models, et al. Should you wish to contact us directly by email, please use http://equalit.ie/#contact
- [View source↑]
- [History↑]
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| Protocol name | 3 | 14:14, 30 September 2014 |
| To-Dos for release candidate | 0 | 17:51, 6 August 2014 |
| Transport reliability | 1 | 15:58, 4 August 2014 |
| Rename "broadcast scheme" | 1 | 23:14, 2 August 2014 |
I'm hesitant about "mpOTR". 2-party OTR works well on IRC, even though messages may be dropped. But in the group setting, in order to ensure transcript consistency, you basically require reliability which IRC does not do. So the current proposal can only work for XMPP.
OTR doesn't do transparent consistency, that's why it works well on IRC :) The original mpOTR proposal consistency check also fails on IRC pretty often so that's why I think there is no harm calling it mpOTR. Beside OTR for "off the record", the important features are deniability and confidentiality (strengthen with forward secrecy) and consistency check isn't even part of the OTR concept (probably that's why it wasn't a concern in the OTR protocol).
I'm don't like mpChat, has nothing to do with confidentiality etc.
I think now that Cryptocat isn't directly under umbrella of eQualit.ie, it isn't relevant enough. Beside people has raised concern about the name and considering the situation isn't
Because we are following all requirements of the original OTR, I think it is fair to use OTR string in the name. Maybe something like what Trevor suggested makes more sense to avoid confusion from the original mpOTR paper. What about mqOTR, it is a sequel to mpOTR and has the Q from eQualit.ie and the belle province :) just a suggestion.
OK, now that we were barred from using OTR accronym, my new suggestion is mpSeQ, motivation:
1. so sound mpSec for multiparty secure (messaging). I believe we are doing more than just being off the record (authentication, consistency, etc). Being provably deniable is just another security aspect of the protocol. 2. eQ for equalit.ie. 3. It might be used for more than instant messaging, so more like multiparty communication or collaboration. So "messaging" part is less crucial to appear in the name.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this 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 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.
> In my opinion mpCAT should be like SSL and IPSEC, the messaging transport control protocol (MTCP) should act like TCP...
We are working on end-to-end security principles, which applies for reliability too. TCP reliability is on the transport layer, not end-to-end between clients working on separate TCP connections. XMPP MUC reliability helps, but is not general enough: as I noted in the other thread, typically public services do not have the incentive, and cannot afford (due to threat of DoS) to offer unconditional reliability - they can only offer limited reliability, i.e. finite-time buffer or finite-message buffer, as experienced on real-world MUC servers.
As I explain in msg-notes, consistency is closely related to reliability; therefore it's best done within the end-to-end reliability layer. For example, your proposed scheme fails badly in the general case where the server cannot provide end-to-end reliability.
I agree that deniable authenticity and forward-secure confidentiality is best done in a separate layer, though. The idea of separation is good, but I disagree with how you're choosing to separate things, based on my research into the consistency problem.
> I think assuming extra ordinary config/storage/abilities for the server, defeat the purpose of end-to-endness. If some participants are malicious...
Context for others: this is for a server-dictated order that supports end-to-end reliability.
Participants might innocently drop for longer periods than the server is willing to buffer (due to potential maliciousness). However, you as the end client implicitly trusts your friend, so you are happy to buffer your own messages for them. Large public servers cannot make this assumption for all their users.
The server adding a sequence number, is zero-cost and (not considering migration costs) should be easy and reasonable to implement. It will enable end-to-end reliability, not guarantee it - the actual recovery behaviour would be implemented on the clients.
> .. 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).
I think it would be better to just automatically re-run the GKE when inconsistency is detected. Why wait until the next group key exchange?
But I think this sort of solution is not ideal, and results much greater overal complexity; consistency and reliability should be done as part of the same layer, because it is simpler and more natural that way.
> .. 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.
To explain why this viewpoint is naive and narrow: your layer mpCAT, makes assumptions that do not apply in the more general case. The way you calculate consistency, assumes global-totally-ordered (linear) reliable delivery; it cannot work in a less strict scenario such as serverless broadcast, even though theoretically we can achieve consistency in those scenarios (e.g. via causal ordering). So, general (i.e. transport-agnostic) reliability systems do not try to achieve this property, so you will not be able to "layer" mpCat on top of it.
The only way a reliability layer can achieve this property (i.e. to ensure your assumption holds), is to require the server changes I mentioned (global explicit sequence numbers) and implement end-to-end recovery in the clients based on this information. This is a fine path to go down, but no reasonable person should call this "transport-agnostic", since it requires server changes which other protocols may not want to adopt (if the protocol even has servers).
TL;DR: the currently-proposed protocol is not transport-agnostic due to an assumption that is fundamentally transport-specific (global total-ordering). No "layering" strategy will enable the protocol to be transport-agnostic; only changes to the protocol itself that don't make this assumption will enable it to achieve this.
By "broadcast scheme", this refers collectively to the peer-to-peer pairwise broadcast, or the "sender keys" optimisation on top of it. I think "broadcast scheme" is too generic and confusing. How about "p2p-broadcast", "full-broadcast", "sender-broadcast", or "member-broadcast"?
I also disagree with "Each participant will have its own different $plist_i$ which is able to broadcast too.". In all schemes, every member should eventually reach the same plist as everyone else. In all schemes, there will be a period where different members have different plists - e.g. even in the GKE case, some members will receive the final round of the GKE earlier than others, so switch to the new plist earlier than those others.
The key difference is that in the p2p-broadcast case, (optionally) members are able to *provisionally send* to the new plist earlier than some other members do, without receiving a key confirmation (and with a forward secrecy penalty if there was an active attack).
I don't think any of those schemes are fundamentally different. The fundamental difference in threat model (and in implementation) is can we start sending message before everybody a reach same view of the room or not.
Original mpOTR doesn't allow it and it is much simpler in implementation and we have security proof for it. My guess is that it doesn't make a huge difference in user experience in majority of xmpp usages. It is also not hard to tweak the code and algorithm to fall back to the different view scenario, that is why I prefer to go with that.
