On 18.12.19 15:05, Marvin W wrote: > 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).
That assessment is correct. That is why, for example, XEP-0359 § 3. 2.
exists.
I can not rule out that we can potentially even further increase the
reliability of the xep359-id-by attribute behind what XEP-0359 already
specifies. But I believe this to be far easier and achievable compared
to, if we do not use the xep359-id-by when referring to messages, coming
up with rules which xep359-id to use depending on the specific situation.
> 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>
> […] 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.
As written above, we aim for xep359-id-by being not spoofable. Exactly
to prevent what you described.
> 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.
I do think actually that this is not the same reason. It is just
sensible to default the xep359-by-id to the MAM archive's address when
performing MAN queries. Of course, a future MAM query extension could
allow for queries using (xep359-id, xep359-id-by).
> so tl;dr: Usually the by is not required when referencing a message as
> it's value is implicit for the usecase.
I would slightly modify this statement: it is implicit for *some* use cases.
Now let's assume that your XMPP server is so kind and archives all
(message) stanzas in your user archive: including all 1:1 chats, MUC,
MIX and future yet to be invented groupchat protocols, providing you
with the ability to lookup (group)chat messages long after the groupchat
hosting service went offline. If the messages within that archive use
only (xep359-id) and not (xep359-id, xep359-id-by) to reference other
messages in the archive, then you run potentially at least into the
following issues:
- the xep359-id within the archive may not be unique, for various
reasons:
- implementation bug
- malicious entity
- IIRC ejabberd uses timestamp id xep359-id [1]. An implementation
where the timestamps are in e.g. milliseconds would potentially
generate duplicate xep359-id values (having different xep359-id-by
values)
- it may not be clear which xep359-id-by value implicitly to use for a
given reference, because the information about the use-case is gone.
- Florian
1: Which appears to be a violation of the xep359 rules, but it is a
different discussion if we may want to change/weaken the "do not leak
information through the xep359-id value" requirements.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
