On 22/02/2023 20.59, Tedd Sterr wrote:
> …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").
There is nothing stopping me from reproducing your stanza ids elsewhere,
but that causes no problem unless there is interaction with an entity
who already received a stanza with such an id - which it should be
checking for anyway, regardless of 'by' value.
The following is an example of an potential issue if we would only use
origin-id to reference stanzas in groupchats:
<message from=alice to=groupchat origin-id=super-unique>
<body>I like cats</body>
</message>
<message from=bob to=groupchat>
<reaction>
<reference id=super-unique>
<action>👍</action>
</reaction>
</message>
<message from=mallory to=groupchat origin-id=super-unique>
<body>I do not like cats</body>
</message>
Now the message from mallory prevents every subsequent message to
reference the initial message from alice. No more thumbs up for cats
(*sad cat noises*).
Even if RFC stanza IDs would be specified to be unique over a broader
scope, this problem would persist.
"But the groupchat could reject the message from mallory based on the
duplicate ID its using!" you say? Sure, it could, but that requires the
groupchat to keep an index of all previously seen origin-ids. And those
are IDs generated by an entity external to the groupchat. This is bad
for essentially the same reasons that you do not want to curate an
archive based on externalized IDs (see one of my previous messages).
So, no, the problem is not "that the original RFC-defined 'id' attribute
had no such requirements", as you put it.
> Referencing messages via such IDs is hence worrisome at best, or simply
> insecure at worst.
Referencing messages by any non-encrypted value (or even message
content, for that matter) is simply insecure; there is no way around
that in a publicly federated network where any hop could potentially
alter a message.
I fear, I do not see how encryption solves anything in that case.
> <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.
Let's assume that every hop appends its own <stanza-id/> because you can
never fully trust that the previous one wasn't altered - which stanza-id
does a recipient use? The only stanza-id you can reliably trust to be
'real' is the one you received the stanza from, and so all previous
stanza-ids should be ignored, in which case each hop may as well strip
and replace them with its own. In that case, you already know who the
stanza-id is 'by' and it is the only one.
I think for the typical groupchat scenario, there are potentially two
stanza-id that you sensibly trust and that are valuable. The one of the
groupchat's archive, and the one of your archive. There may be also the
stanza-id of the sender's archive, but this is primary valuable in
carbon copies of the sender, so that the sender's devices learn the ID
the message was archived in the sender's archive.
Hence, I do not believe that there should be as many stanza-ids stripped
as you said. In fact, I would not strip or replace any stanza-id in that
case, only in the cases that xep369 mandates.
- Flow
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
