[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

Steve Kille 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
> Lukas
> 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."
[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] 


> > 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] 


More information about the Standards mailing list