jdev - 2024-07-08

anyone that has knowledge of MLS can answer how good is MLS ordering? I am browsing the RFC now and I stumbled on the > 15.3. Delayed and Reordered Application Messages which says > Since each application message contains the group identifier, the epoch, and a generation counter, a client can receive messages out of order. When messages are received out of order, the client moves the sender ratchet forward to match the received generation counter. Any unused nonce and key pairs from the ratchet are potentially stored so that they can be used to decrypt the messages that were delayed or reordered. reading the rest of the RFC it seems to suggest that epoch and generation identifier together with other things like the rachet tree could give a pretty close indication on message ordering am i reading this right?

also how close is this to omemo? is it that omemo doesnt have the generation counter so we are using the timestamps to compensate?

or maybe because omemo is not used everywhere we can't rely on omemo actually

https://http.icebound.dev/httpfileupload/I4i4qra07vrf3DOgiO_yrc-lHGQ/Screenshot_20240708-144409_monocles%20chat.png

How does this client knows that sending private messages is forbidden in the MUC ?

There is a configuration option in XEP-0045, grep for 'allowpm'

But as mentioned, it's problematic because it isn't able to reflect more fine-grained policies (such as "only PMs with moderators are allowed", which this MUC implements, for example)

Ok :)

There is also no equivalent disco item defined in XEP-0045 as far as I can see

Probably implementations made one up

Yes that's my main problem

all configuration options can be exposed in disco, when i remember correctly

and for example ejabberd does it with the pm setting if i remember correctly

its called muc#roomconfig_allowpm

> is there any movement to make the MUC config/members list authenticated somehow and with access to specific people only? coming back to this MIMI uses an RFC that hasnt been finalized that uses MLS to do something related to that. https://datatracker.ietf.org/doc/draft-barnes-mls-appsync/ could be interesting to see it in practise if we can shove a config in there :P

Does anyone have experience with a misbehaving XMPP entity that sends `<nessus/>` on a c2s connection (as a first-level element on the stream, where you'd expect `<iq/>` `<message/>` or `<presence/>`)?

Guus: it's probably the security scanner

Similar to nmap it will send junk to fingerprint software and identify vulnerabilities