Missing PEP/PubSub feature announcement
Closed this issue · 10 comments
The XEP-0030 disco on the user's account does not announce http://jabber.org/protocol/pubsub#subscribe support (despite announcing http://jabber.org/protocol/pubsub#publish and others).
This is likely a bug and prevents Monal from detecting PEP (XEP-0163) as supported which in turn is needed for OMEMO to work properly.
@tmolitor-stud-tu: To follow this ticket.
Looks like we only need to add "subscribe" over there: https://github.com/maranda/metronome/blob/master/plugins/mod_pubsub.lua#L105 ?
Hm, no. There is "subscribe", but I don't get on what it announcement depends.
@tmolitor-stud-tu good day, after reviewing the code. Metronome doesn't support explicit node subscription but only access-presence / auto-subscription ... what is honestly missing is the 'auto-subscribe' feature and not the subscribe one. It's not mandated anywhere that a service advertising auto creation should support explicit subscription as well for publish in nodes.
Without explicit subscription omemo in groupchats won't work properly if not all participants have mutual presence subscription with each other.
That means my initial assertion that only the disco feature is missing was wrong, but the actual feature and the disco feature are missing.
that means the issue is even worse.
No it's not, https://github.com/maranda/metronome/blob/master/plugins/auxlibs/pep.lib.lua#L201 it's again just a question of implementation, if you set the access model to open to the public keys node that won't be an issue also Metronome MUC does support routing of arbitrary payloads directly to the bare jid and pep is added by default (so in theory you don't even need to know the real jid to query the node).
Open access model was specifically added to allow access to microblogging comment nodes without presence subscription, and can and should be used the same to allow access to public key nodes in OMEMO.
AFAIR that's what C does and/or did, I used OMEMO in MUC a few times and without too many issues, unfortunately OMEMO e2ee in MUCs just is badly designed and doesn't scale but that's another story.
I'm not talking about the public keys node but about the devicelist node.
How can I (as a client) get updates of the devicelist if I can't subscribe to the devicelist?
Sure, I can proactively fetch every devicelist after every resource bind (that would create more traffic than needed, but is doable), but what about updates of the devicelist (new added devices or removed devices)? How do these updates on a remote account reach my device?
This is security relevant: if I still use the old devicelist I might encrypt for a device already removed.
And UX: I might not encrypt for a new device already added.
As for the MUC routing stuff: querying pep through the MUC is something not usually done by any client. But in theory it would allow omemo encrypted public channels, which is kind of nice but on the other hand useless because public channels are...ehm...public, so encryption is kinda useless.
Are we talking about OMEMO in groupchats or something else..?
Anyways XEP-0384 itself recommends that access model of the devicelist is set to open to allow establishing of sessions by entities without presence subscription in 5.3.1 and in 5.8.2 it says:
Before sending a message a participant MUST explicitly fetch device lists (if not already cached) for each of the members.
So at regular intervals you should explicitly refetch the device list anyways, I agree it's not exactly the best, but neither is relying exclusively on node update broadcasts because:
A) a server may arbitrarily decide to not send you an update (if it's resource constrained for example)
B) stanzas may get lost in transition if there're connectivity issues between the servers
C) and that's this case, the server may have a limited PubSub feature set available to PEP and not support explicit subscriptions
7.1 also clearly states what are the PEP requirements for OMEMO support server-side and #subscribe is not one of 'em
Yes, we are talking about omemo in groupchats.
No, fetching the devicelist every time before sending a message is not feasible. And caching is a hack because security, UX as well as the generated traffic greatly depend on the selected caching timeout and usage scenario (for some scenarios a longer timeout may be okay, for others it won't).
Especially on mobile devices!
- As of case A: to my knowledge neither ejabberd, nor prosody or openfire arbitrarily filter out pep stanzas, so I consider that a badly behaving server.
- Case B on the other hand should not occur very often and a broken s2s will introduce other problems, too (messages not being delivered, for example). I consider that out of scope (and the proper fix would be to use something like XEP-0198 on s2s connections or invent some other reliability improving measure).
- Yes C is your server.
7.1 also clearly states what are the PEP requirements for OMEMO support server-side and #subscribe is not one of 'em
yes, those are the absolute minimum requirements to make it work somehow. In case of missing subscribe this means regular polling. I won't resort to such hacks given that other popular servers (ejabberd, prosody, openfire) all support #subscribe (and polling is especially bad on mobile devices not being permanently connected).
To sum it up: Yes, it is possible to work around missing #subscribe support, but these hacks are far from optimal and I therefore consider a server not supporting #subscribe as not being ready for omemo.
Sidenote: the omemo spec implemented by most clients is OMEMO1 specced in XEP version 0.3.0 over here: https://xmpp.org/extensions/attic/xep-0384-0.3.0.html
Yes so to sum it up, Monal problem, Conversation works case closed :)