[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))
steve.kille at isode.com
Thu Dec 7 16:01:42 UTC 2017
> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Georg
> Sent: 07 December 2017 14:52
> To: standards at 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.kille at 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."
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
> > 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?
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
> 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
> 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
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.
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.
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.
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.
> > 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?
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.
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.
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.
More information about the Standards