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

Dave Cridland dave at cridland.net
Thu Dec 7 15:21:38 UTC 2017


On 7 Dec 2017 15:52, "Georg Lukas" <georg at op-co.de> wrote:

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."


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-unsubscribe at xmpp.org
_______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171207/37af553f/attachment.html>


More information about the Standards mailing list