24 Dec
2024
24 Dec
'24
10:32 a.m.
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.
24 Dec
24 Dec
11:19 a.m.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
7:19 p.m.
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(a)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.
119
days inactive
120
days old
2 comments
2 participants
participants (2)
-
Dave Cridland -
Philipp Hörist