On 7 Dec 2017 15:52, "Georg Lukas" <ge...@op-co.de> wrote: Hi Steve,
thanks for your feedback. Please allow me some more remarks. * Steve Kille <steve.ki...@isode.com> [2017-12-07 14:03]: > > | 13. Although some protocol is shared with MUC, MUC clients are not > > | interoperable with a MIX service. This means that where a user > > | chooses to use MIX, all of the users clients need to support MIX. > > Is that still a requirement / concept? > Yes. This is quite fundamental to the way MIX works. Sorry for not quoting clearly. My question was only in reference to "all of the users clients need to support MIX." Yes, I don't think that's right, in as much as a MIX service can be a MUC service *too*. But in order to support a MUC client, the service *also* has to offer MUC. MIX is not backwards compatible with MUC, and a service wishing to support MUC clients will need additional protocol support. > > §6.1.1 Joining a Channel > The update made to the user's roster needs to be reflected back to ALL clients. This will happen by "normal operation". I will add text to make this clear. > The client experience will be that if one client adds a MIX channel, that this will then appear in the roster of all the user's online clients. The client also needs a way to distinguish that from a regular contact roster push, so it can set up the MIX accordingly, and configure its packet listeners. It would be good to have a defined order of events like it is in MUC, e.g. first the roster push, then an update of the nodes subscription state, then individual node contents? > > §6.1.14 Retracting a Message > The retract goes into the message stream, so clients will get this in they way they get all new messages to a channel. > > I will add a note on timeframe, allowing servers to time limit when retract applies. I think I didn't make my point sufficiently clear. The problem I see with having <retract> in the message stream is that it contains the message ID, which is only known to the submitting user. So the server needs to rewrite the ID in the payload to the archive ID of the reflected original message. That implies that both the sender and the service need to keep a mapping between those IDs even after the initial message forwarding. This is why I was asking about the timeframe, as that mapping might be considered as volatile information. If, instead, the initial <retract> element contains the MAM ID, a client has to wait for reflection before a <retract> is possible, which is not too much of a problem IMO. (But then you need to change the XEP to reference the MAM ID) > LMC is simply a new message updating the previous one. > Retraction removes the message from the record, which can be important. If you remove a message from the record, you will break MAM-ID based synchronization and cause inconsistencies between clients (depending on whether they received the <retract> or did a MAM sync afterwards). Therefore, the only consistent approach I see is the tombstone replacement. > It is a simple and clear spec, so I think fine to leave in core MIX. My feeling is that 0369 is already too long and too complex, and that moving <retract> into its own XEP (or maybe merging into LMC) would be better. > > §6.1.16 Inviting another User to join a Channel that the user does not > > have Permission to Join > I think that having the information explicit is going to help both > implementation and deployment. It makes things easier of you can > clearly see what the invitation is doing. I don't see any real > benefits in removing the information. Except for security considerations. If you duplicate the information, an attacker can modify it and trick implementations into undesired behavior, e.g. by making someone join a MIX by sending a message with the <inviter> field set to a contact of the victim. If you add a field in a security-relevant protocol, all implementations need to check that field for validity. If they don't check, they become vulnerable to manipulation of that field. > > §6.5.4 Converting a 1:1 Conversation to a Channel > Here is how I propose to address this. > > 1. Require that if history is added, it is done by the user creating the room before any other client is added. Allowing history to be added later is I think too risky, This is a mitigation for one of the two possible attack vectors. From the mentioned Carbons experience I think that the overall feature is very error-prone, and hard to implement in a secure way. > 2. Recommend that when the other 1:1 client joins the room that it validates the history. If it does not match, alert the user, who can take appropriate action. Technically, this will be complicated to achieve. Also, what if the validating user is not available when the third user joins, and can not act upon the detected mismatch? I'd rather have a specification that requires a certain display for <forwarded> messages, where the user can clearly see that it's not an original from Bob but has been forwarded by Eve. > > §8. Supporting MIX and MUC together > I think that the partially integrated approach remains a good option. I believe that many implementers will want to take this approach. The fully integrated approach has a number of non-trivial issues to address and I think it would be a serious mistake to not include the partially integrated approach. I think that the fully integrated approach is The Right Thing, and fits well the original XMPP mantra of smart servers, dumb clients. I also think that a half-hearted "linked channels" approach will come with many quirks and interop problems due to the large number of possible feature combinations, and that we already have more quirks and interop problems than we can handle. Furthermore, it might have interesting security implications, where the linked MIX and MUC are in different trust domains (or where an attacker links to a MIX/MUC outside of their control). I would really love to hear about implementation experience of the fully integrated approach, and whether the non-trivial issues can be sorted out. If there are show-stoppers, we need to change the protocol until there are none. If we can't fix the protocol, then (and only then) I might change my opinion about the partially integrated solution. Georg _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
