Hi all, Further to the note in the LC thread on XEP-0424, I'd really like to have a document (XEP, probably) that answers these questions: What are the risks of choosing an stanza identifier that is not unique? Does this still matter if the stanza identifier is unique to the session? To the sending jid? To the bare jid of the sender? What about missing off the stanza id attribute entirely? What about MUC? PubSub? Etc? If people have opinions, write away, and I'll volunteer to collate these into a XEP (or, possibly, a patch against XEP-0359). My reasoning is that we seem to vaguely know things can get Bad, but I for one can't find where we've documented these Bad Things. I'd be delighted to be corrected, as ever. Dave.
Sounds nothing that can be answered without a specific context (e.g. in context of a specific XEP and use case) What we could do is list the different IDs and its attributes and a recommendation for the use case in which they are good and bad and why. For Example Message ID: - Not Unique - Chosen by the sender Should not be used: - Whenever its critical to identify a specific message Can be used: - Whenever it does not hurt to identify a wrong message, or if there is another attribute that in combination allows to identify the correct message (e.g. LMC Attribute "It must be the last message sent/received") Recommendation: Do not use for new XEPs, if for a use case a XEP needs to depend on client generated IDs (Non-MUC), use origin-id. Just an example, i do not claim correctness on this example. Regards Philipp On Tue, Dec 24, 2024, at 16:32, Dave Cridland wrote:
Hi all,
Further to the note in the LC thread on XEP-0424, I'd really like to have a document (XEP, probably) that answers these questions:
What are the risks of choosing an stanza identifier that is not unique?
Does this still matter if the stanza identifier is unique to the session? To the sending jid? To the bare jid of the sender?
What about missing off the stanza id attribute entirely?
What about MUC? PubSub? Etc?
If people have opinions, write away, and I'll volunteer to collate these into a XEP (or, possibly, a patch against XEP-0359).
My reasoning is that we seem to vaguely know things can get Bad, but I for one can't find where we've documented these Bad Things. I'd be delighted to be corrected, as ever.
Dave. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
It's just ticked over into Christmas Day, so before anything else, Merry Christmas! On Tue, 24 Dec 2024 at 16:20, Philipp Hörist <philipp@hoerist.com> wrote:
Sounds nothing that can be answered without a specific context (e.g. in context of a specific XEP and use case)
I'm not so sure.
What we could do is list the different IDs and its attributes and a recommendation for the use case in which they are good and bad and why.
For Example
Message ID: - Not Unique
Always at least unique to the stream. RFC 6120 allows this; I think it'd be useful to ensure these are globally unique instead - not only for the benefit of other entities, but (I suspect) the originating entity itself.
- Chosen by the sender
All ids are chosen, and origin-id is also chosen by the sender. What attacks are there if an attacker deliberately reuses an id? (For retraction, possibly that an attacker can make some clients retract the first message, and others retract a subsequent message).
Should not be used: - Whenever its critical to identify a specific message
Like, say, type="error" bounces? Or receipts? Or chat markers? We're doing all these *all* the time. We don't - ever - identify a message by just the id (or if anyone's doing that, then please stop). We identify using an id and a jid - and the interesting cases (see other thread) start when we want to scope other than a full jid of an online client.
Can be used: - Whenever it does not hurt to identify a wrong message, or if there is another attribute that in combination allows to identify the correct message (e.g. LMC Attribute "It must be the last message sent/received")
Recommendation: Do not use for new XEPs, if for a use case a XEP needs to depend on client generated IDs (Non-MUC), use origin-id.
I'm more interesting in documenting the problems rather than looking for solutions at this stage. Should solutions be obvious - and one such is that we should just mandate that the attribute id is always present, and always globally unique - then let's do the sensible choices instead of workarounds like origin-id. Dave.
participants (2)
-
Dave Cridland -
Philipp Hörist