[Standards] Proposed XMPP Extension: Message Fastening

Marvin W xmpp at larma.de
Wed Dec 18 14:05:43 UTC 2019

I think the guarantee of uniqueness for (xep359-id, xep359-id-by) is not 
helpful if the xep359-id-by entity cannot be trusted to be xep359 
compliant (= non malicious).

This is for example the case in public MUCs. In fact in MUCs, there is 
only one xep359-id-by that can/must be trusted, which is the MUC itself. 
Thus for MUCs, the xep359-id-by being the MUC is basically something we 
could imply, because in general, other xep359-id-by can not be trusted.

In direct messages it's not that clear, however it is also obvious that 
the xep359-id-by must be either the sender or the recipient's origin-id 
(the MAM stanza id are different on each server and cannot be seen by 
the other user, so can't be used for anything). If any of the two does 
not follow the recommendation to generate globally unique IDs, not 
providing the by attribute may cause issues. However for this to cause 
issues, it needs one of the two to act malicious, because even if you 
don't guarantee unique ids, collisions are very unlikely if not caused 
intentionally. If they act malicious, then even providing a by attribute 
won't solve anything, as malicious actors can just decide to not follow 
the uniqueness requirement of (xep359-id, xep359-id-by) as well.

For the very same reason, you don't need a by when requesting messages 
by id from MAM, because the id must always be the one assigned by the 
archive server.

The only reason why I could imaging the by attribute to be useful would 
be server-side rewriting (which for example won't work for e2e-encrypted 
messages and also requires indefinite server history): When by is set 
and the id is in the archive, the server could replace the by/id with a 
better suited one (that is known to the intended recipient). This way it 
would possible that clients would be fine with only ever knowing one id 
of a message (the local servers archive id) and all other ids can be 
ignored (or even redacted by the server). However I don't think this is 
something we'd like servers to do (for various reasons and because of 
the problems mentioned).

so tl;dr: Usually the by is not required when referencing a message as 
it's value is implicit for the usecase.

On 12/18/19 11:59 AM, Florian Schmaus wrote:
> Oh, the IDs are unique. But only if you concatenate the 'by' value with
> the ID. Or, in other words, the tuple (xep359-id, xep359-id-by) is
> guaranteed by xep359 to be globally unique.
> One reason why xep359 makes this distinction is to prevent ID spoofing.
> Consider an archive which contains a message with the xep359-id 'id1'
> and another user now refers to this message just using 'id1'. If now an
> (malicious) entity would be able to add to the archive another message
> with the same xep359-id 'id1', but a different xep359-id-by value, then
> it is not clear anymore which message is refereed to.
> Hence one should always use the tuple (xep359-id, xep359-id-by) when
> referring to stanzas using xep359 IDs. And this is the coordinate system
> fastening should use to establish a link to other messages.

More information about the Standards mailing list