On 22/02/2023 18.00, Tedd Sterr wrote:
But, being serious: the issue is that both clients and servers need an id for referring to stanzas, and if that id is dependably unique then it solves a number of difficulties; the reason we have problems is that the original RFC-defined 'id' attribute had no such requirements, and so id can't be depended upon.
No, that is not the reason we have problems. Even if the RFC would specify something different, we would have problems, because …
So, if the originator of a stanza (sending client, usually) guarantees that its id is unique (and you also trust that guarantee) then there should be no reason for anyone else to add their own id mechanism
…this is the line of thought that neglects that we are working on a federated system where we can not assume that every actor is faithful. ID assigned by the sending entity can potentially be observed by another malicious actor and be reproduced ("spoofed").
Referencing messages via such IDs is hence worrisome at best, or simply insecure at worst.
<stanza-id/> tries to mitigate this by the 'by' attribute, which denotes the entity that assigned the ID, for example a MUC. If the MUC behaves standard compliant, then it will reject (or at least sanitize) incoming messages containing a <stanza-id/> with a 'by' attribute denoting its from the MUC.
Yes, MUCs could also spoof IDs, but at least you only have to trust the MUC and not everyone in the federated network to behave nice.
- Flow _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
