17 Oct
2024
17 Oct
'24
3:27 a.m.
Hi all,
I was skimming XEP-0490, and the optimisation of injecting multiple
displayed elements into a message referencing different ids in different
namespaces made me spit my tea dramatically over my keyboard. Not really,
of course - tea is far too precious to waste on such things, but you get
the idea.
There's clearly no better alternative, because we have clients in the wild
which are quite painful about message ids, and will therefore break things
if we were to rely on their ids being unique.
This got me thinking: What could we do to - if not remove this wart
entirely, at least file it down so it was less of a nuisance. (I'm not sure
if warts do get filed down; I am not a doctor, do not try this at home)
In a perfect world, we might remove XEP-0359 entirely - not because it is,
in and of itself, a bad spec, but because it is essentially patching
problems elsewhere.
So, what can we do to ensure that some tuple of the stanza attributes
perhaps (from,id), or possibly (from,to,id), is unique "enough", and stable
"enough", for both receivers and senders to rely on without having to
inject multiple ids?
Is this worth doing - it feels like it would clean up a lot of other
constructs, but some cases (MAM, perhaps?) might always need to inject
other identifiers. If we were to rely on clients using unique identifers,
could this be subverted in some way beneficial to an attacker?
My gut feeling is that even if we find that we're stuck with XEP-0359 in
all the same cases, we might produce an interesting document about the
security implications of the id attribute of stanzas, which feels like a
gap worth filling.
What do you all think?
Dave.
17 Oct
17 Oct
5:09 a.m.
Well, good morning, the lack of stable stanza IDs was the biggest problem
in XMPP ever. For ourselves, we fixed it the following way:
1. Each server generates unique stanza IDs according to XEP-0359.
2. Attached Stanza IDs are relayed as they were, and local server assigns
own IDs for incoming and outgoing stanzas.
3. When interacting with the message, clients and server interact using own
IDs.
4. For outgoing messages, the client assigns a provisional unique ID for
the message and sends it away. The server assigns a unique server ID to the
message and relays the message to its destination, and sends a receipt with
the server ID to the client. Client considered the message as unsent until
it receives that receipt, and retries sending it until it obtains said
receipts.
5. XEP-0333 was extended and we put all stanza IDs into <displayed />, so
both local and remote server can use their respective IDs.
We call XEP that describes point 4 from above as XEP-DELIVERY (when you get
numbers in high hundreds it gets really silly), its draft text can be found
here
<https://docs.google.com/document/d/1UmHx_ryCW1lffMiwv1ONSjvZL2cO5pd9OOPxT-banK0/edit?usp=sharing>
.
On Thu, 17 Oct 2024 at 14:33, Dave Cridland <dave(a)cridland.net> wrote:
Hi all,
I was skimming XEP-0490, and the optimisation of injecting multiple
displayed elements into a message referencing different ids in different
namespaces made me spit my tea dramatically over my keyboard. Not really,
of course - tea is far too precious to waste on such things, but you get
the idea.
There's clearly no better alternative, because we have clients in the wild
which are quite painful about message ids, and will therefore break things
if we were to rely on their ids being unique.
This got me thinking: What could we do to - if not remove this wart
entirely, at least file it down so it was less of a nuisance. (I'm not sure
if warts do get filed down; I am not a doctor, do not try this at home)
In a perfect world, we might remove XEP-0359 entirely - not because it is,
in and of itself, a bad spec, but because it is essentially patching
problems elsewhere.
So, what can we do to ensure that some tuple of the stanza attributes
perhaps (from,id), or possibly (from,to,id), is unique "enough", and stable
"enough", for both receivers and senders to rely on without having to
inject multiple ids?
Is this worth doing - it feels like it would clean up a lot of other
constructs, but some cases (MAM, perhaps?) might always need to inject
other identifiers. If we were to rely on clients using unique identifers,
could this be subverted in some way beneficial to an attacker?
My gut feeling is that even if we find that we're stuck with XEP-0359 in
all the same cases, we might produce an interesting document about the
security implications of the id attribute of stanzas, which feels like a
gap worth filling.
What do you all think?
Dave.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
31
days inactive
31
days old
1 comments
2 participants
participants (2)
-
Andrew Nenakhov -
Dave Cridland