Georg, > -----Original Message----- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Georg > Lukas > Sent: 07 December 2017 14:52 > To: standards@xmpp.org > Subject: Re: [Standards] UPDATED: XEP-0369 (Mediated Information > eXchange (MIX)) > > 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." [Steve Kille]
The wording is overly tight. I will rephrase. You can clearly use MIX if only some of your clients support MIX. > > > > §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? [Steve Kille] It will be a regular roster push. MIX clients can distinguish MIX roster elements by the extension that defines it. For other clients, this is just a normal roster update. I don't think that any change is needed. > > > > §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) [Steve Kille] You're right. The fix is straightforward - change Retract to use the MAM ID. I think that retracting a very old message has potential issues, which are still worth noting. > > > 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. [Steve Kille] Yes - tombstoning will work best. I think that the sync problem is nasty, and that the right solution is to mandate tombstoning. > > > 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. [Steve Kille] This is a page of text. Easiest to leave where it is. If this is a problem when we get to draft, can split it out then. > > > > > §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. [Steve Kille] I am not convinced that we should change. Suggest we defer further discussion until we have implementation experience. > > > > > §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. [Steve Kille] OK, > > > 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? [Steve Kille] This is hard, which is why I suggested optional. I think that the check is still worth noting. > > 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. [Steve Kille] I'll add a note on this point. Spec should not mandate the UI, but seems sensible to note risk and possible UI mitigation > > > > > §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. [Steve Kille] I think that both approaches should be documented for now. I will be highly resistant to changing this. We need to get implementation and deployment experience. As a result of this, it seems possible we may eliminate one of fully integrated/partially integrated from the spec. > > > > Georg [Steve Kille] Steve _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
