Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
In my imaginary world where all stanzas have UUIDs there would be no need for anyone else to add their own id because every stanza already has a unique id which is suitable for referencing in various archives (and the risk of collisions is acceptably close to zero.) Of course, that depends on trusting that everybody else is both competent and not malicious; while that is true most of the time, we still have to cover for the few times that it's not. So, everyone adds their own id because they can't trust anyone else's ids, though those are still useful for referencing with the entities who added them. We should still aim to limit revealing ids to places where they are relevant, rather than piling multiple ids everywhere just because someone in the chain wanted one for their own purposes. I don't care what id you're using to store messages in your local archive, I could not use that information even if I wanted to, and arguably it's a data leak. If I send a message to the MUC: ... Then I should receive back: ... I can cross-reference with the original message I sent using origin-id (uuid_001) because that is the id I used. I can reference a message in the MUC by using stanza-id (uuid_002) because that is the id the MUC used. If I want to reference a message in my server's archive, I can use message.id (uuid_003) because that is the id my server used; if there is no server archive then stanza-id.id will be the same as message.id (and stanza-id is duplication, but included for simplicity.) And you should receive: ... You can't reference the original message I sent, and there is no legitimate reason you should. To reference a message in the MUC, you can use stanza-id (uuid_002). And to reference a message in your server's archive, use message.id (uuid_004). Each endpoint should add its own new uuid into message.id, since that's the one it recognises for referencing; and stanza-id is added to provide the id used by the original sender (the muc), rather than trying to use the same id in two different places for different purposes. If you like, there is an implicit 'by' on the stanza-id with the value equal to message.from (minus nick.) Is the above something we can move towards, or are there practical reasons that it's not possible/realistic? And is there a need for yet more ids to be exposed to genuinely interested parties? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
On 25.02.23 10:57, Marvin W wrote: On Sat, 2023-02-25 at 10:39 +0100, Florian Schmaus wrote: As I wrote before, if, for example, the recipient's server also stores groupchat messages in the user's archive, then the recipient will receive a groupchat message containing (at least) two stanza-id elements: - one added by the groupchat, with the ID under which the stanza was stored in the groupchat's archive - one added by the recipient's server, with the ID under which the stanza was stored in receiving user's archive If non-authoritative, intermediary archives exist, they may want to archive the message under a different id than the "one and only" message stanza id in the id-attribute and in that case they could add an element or something, making clear that this is not an id of the stanza, but merely the id the message is archived under in the given archive. The same element could even be used in reply by your local server and in carbons to tell the client which id is used for archiving the message in the local archive. I know that we currently use for that, but that doesn't really convey the semantic of that being the id for the archive entry and rather gives the feeling that this id is an id for the stanza - and right now we even do give it extra meaning outside being an archive id in the MUC context. I would hope that xep359 makes it clear that IDs found in stanza-id are the IDs an entity gave to the given stanza. If not, then we should improve upon this. After all, stanza-id originated exactly from what you describe with " > "…this id is an id for the stanza…" It certainly is. But your mindset appears to be that a single stanza can have only at most one ID. However, messages (or stanzas in general), can have multiple IDs, assigned by different entities. True, the stanzas may not be exactly equivalent in each archive, simply because hops may add additional extension elements to them (or modify existent). But from a pragmatic point of view they are the same stanza. - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
On Sat, 2023-02-25 at 10:39 +0100, Florian Schmaus wrote: > As I wrote before, if, for example, the recipient's server also > stores > groupchat messages in the user's archive, then the recipient will > receive a groupchat message containing (at least) two stanza-id > elements: > - one added by the groupchat, with the ID under which the stanza was > stored in the groupchat's archive > - one added by the recipient's server, with the ID under which the > stanza was stored in receiving user's archive If non-authoritative, intermediary archives exist, they may want to archive the message under a different id than the "one and only" message stanza id in the id-attribute and in that case they could add an element or something, making clear that this is not an id of the stanza, but merely the id the message is archived under in the given archive. The same element could even be used in reply by your local server and in carbons to tell the client which id is used for archiving the message in the local archive. I know that we currently use for that, but that doesn't really convey the semantic of that being the id for the archive entry and rather gives the feeling that this id is an id for the stanza - and right now we even do give it extra meaning outside being an archive id in the MUC context. Marvin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
On 24.02.23 16:47, Tedd Sterr wrote: What I'm less sure of is the benefit 'by' actually brings in practice. If there are multiple stanza-ids then it obviously serves to differentiate them, but why the need for multiple? The client's id is the origin-id (so it can cross-reference with its archive) and the MUC's id is the stanza-id (so it can be referenced for reactions, etc.) Carbons shouldn't need yet another id. As I wrote before, if, for example, the recipient's server also stores groupchat messages in the user's archive, then the recipient will receive a groupchat message containing (at least) two stanza-id elements: - one added by the groupchat, with the ID under which the stanza was stored in the groupchat's archive - one added by the recipient's server, with the ID under which the stanza was stored in receiving user's archive If the sending user's server also stores all groupchat message in the sending user's archive, then there could be easily a third stanza-id element. Arguably, the ID of this stanza-id element is in most cases of not much use to the recipient, as the recipient will probably not have access to the sender's archive. Still it may provide useful, and if it is "only" for debugging purposes. The "carbon-to-self" topic is slightly different, but related. We currently have the asymmetry that, in the presence of carbons, other sessions of a user are able to learn the ID under which an outgoing stanza was archived in the user's archive. However the client that send this message does not get this information, because there is no carbon copy to the sending session, only to other sessions. Some developers find it useful to become aware of the archive's ID, so there has been a discussion about how this could be achieved. This discussion is, however, unrelated to our current discussion (I believe). It is only connected by stanza-id being (assumably) the element transporting the desired information. - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
I generally like the idea of the MUC assigning the id to it's outgoing messages instead of using the id proposed by the occupant sending the message. I also think that if we all agreed that we want that, we could migrate to that situation in a backwards-compatible manner: the #stable-id feature, although required by the current version of XEP-0045, is still considered optional for most clients. Removing it and instead adding a #unique-id feature that announces the exact opposite feature (id's are guaranteed to be unique by the MUC) would thus be possible. Some clients send in messages to MUCs that don't do #stable-id, so just reflecting that to those is going to work with those clients. And if there is no the MUC could add one in its reflected message to tell which message id the original sender had. For compatibility you would still add a using the same id that is already in message id- attribute. eventually we'll be able to phase that one out. Marvin PS: Having #stable-id and #unique-id at the same time is still feasible. Yes it requires the MUC to store all ids it ever generated (or at least over a longer period), which may sound like it would need a lot of storage, but in fact this can be done somewhat reasonably in constant-size using math™: https://en.wikipedia.org/wiki/Accumulator_(cryptography) On Fri, 2023-02-24 at 15:47 +, Tedd Sterr wrote: > I think there may be some confusion and we're not even disagreeing > about the same things; so, I'll state my thoughts more clearly. > > The original sender of a message stanza SHOULD give it id=UUID. > Unfortunately, this wasn't a requirement in the RFCs, so now we have > various hacks to try to deal with that because we can't just fix the > problem while maintaining compatibility. > > In the case of MUC messages, the original sender IS the MUC, and not > the client. The client sends its message to the MUC, and that message > SHOULD have its own unique id, but the message which the MUC forwards > to participants SHOULD be a new message with its own new unique id. > But the client wants to cross-reference the message it sent with the > one it receives, and so the MUC SHOULD also insert an origin-id with > the client's original message id (only in the message it forwards to > that client.) > > Now, the above SHOULDs are my own preferences for an ideal world > where we could have nice things, whereas in reality we maintain > compatibility and add 'just one more' id in the hope it solves > things. > > In the above ideal world, MUC message ids can't be spoofed because > they are assigned by the MUC itself. The MUC doesn't even need to > care what id a client used because it assigns its own new id to any > messages it sends - if a client does duplicate one then it only > confuses itself in the origin-id (and nobody else sees that.) I > understand that is effectively what you're trying to address with > stanza-id, and it is a valid solution. > > What I'm less sure of is the benefit 'by' actually brings in > practice. If there are multiple stanza-ids then it obviously serves > to differentiate them, but why the need for multiple? The client's id > is the origin-id (so it can cross-reference with its archive) and the > MUC's id is the stanza-id (so it can be referenced for reactions, > etc.) Carbons shouldn't need yet another id. > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
I think there may be some confusion and we're not even disagreeing about the same things; so, I'll state my thoughts more clearly. The original sender of a message stanza SHOULD give it id=UUID. Unfortunately, this wasn't a requirement in the RFCs, so now we have various hacks to try to deal with that because we can't just fix the problem while maintaining compatibility. In the case of MUC messages, the original sender IS the MUC, and not the client. The client sends its message to the MUC, and that message SHOULD have its own unique id, but the message which the MUC forwards to participants SHOULD be a new message with its own new unique id. But the client wants to cross-reference the message it sent with the one it receives, and so the MUC SHOULD also insert an origin-id with the client's original message id (only in the message it forwards to that client.) Now, the above SHOULDs are my own preferences for an ideal world where we could have nice things, whereas in reality we maintain compatibility and add 'just one more' id in the hope it solves things. In the above ideal world, MUC message ids can't be spoofed because they are assigned by the MUC itself. The MUC doesn't even need to care what id a client used because it assigns its own new id to any messages it sends - if a client does duplicate one then it only confuses itself in the origin-id (and nobody else sees that.) I understand that is effectively what you're trying to address with stanza-id, and it is a valid solution. What I'm less sure of is the benefit 'by' actually brings in practice. If there are multiple stanza-ids then it obviously serves to differentiate them, but why the need for multiple? The client's id is the origin-id (so it can cross-reference with its archive) and the MUC's id is the stanza-id (so it can be referenced for reactions, etc.) Carbons shouldn't need yet another id. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
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:
I like cats
I do not like cats
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.
> 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 with a 'by' attribute denoting its
> from the MUC.
Let's assume that every hop appends its own 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: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
On 22/02/2023 20.00, Marvin W wrote: I believe we only disagree if a reference to a stanza should also contain the 'by' attribute. [And probably about our vision if groupchat messages should be stored in as many archives as possible or just in the groupchat service's archive. But we should simply allow for both approaches, it is from a protocol design perspective not an XOR situation.] - When receiving a message reference: Ignore any "wrong" by-attribute in message references and just take the value that I implicitly know must've been used when referencing (following Postel's law). Following Postel's law in this sense does more harm than good, as you would not be able to detect implementations that operate under different assumptions. Instead, we should allow the recipient of a message to verify that the sender of the message operated under the same assumptions as the recipient. This is only possible if the reference contains the 'by' attribute. This would turn the by-attribute in a message reference into entirely useless boilerplate that is generated out of thin air by the sender and ignored by the recipient. It is not useless boilerplate and certainly not generated out of thin air. If the recipient does use this information is up to the implementation, but I would encourage that the recipient verifies it. - Flow ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
On Wed, 22 Feb 2023 at 13:33, Thilo Molitor wrote: > > There is a very obvious solution to this which everyone seems to be > > overlooking: we need a new element with a guaranteed unique, non-spoofed > > UUID; should a server feel the need to do bad things, it can set the > > 'spoofed' attribute to true and then clients can act accordingly. > what entity would set that element? the sending client? the server of that > client? the server of the receiving client? Any entity that's doing Bad Things of course. See also XEP-0076, RFC 3514. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
> …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.
> 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.
> 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 with a 'by' attribute denoting its
> from the MUC.
Let's assume that every hop appends its own 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.
> 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.
The MUC is the originator of the stanza in this case, so it should assign its
own unique message id. The original sender, who directed the MUC to forward the
message to room participants, will want to match up its sent message with the
one it receives from the MUC - so then it's useful for the MUC to inform (only)
the original sender "this was the id you used when you sent me this message" in
the same forwarded message.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
On Wed, 2023-02-22 at 19:02 +0100, Florian Schmaus wrote:
> That is where we already think different. The more archives messages
> are
> contained in, the higher the chances are that they are preserved and
> recoverable. Which is usually a good thing.
The ground truth for messages received by the user is the receiving
user's server archive - a message that is not stored there should cause
an error to be stored in the sender's archive and thus should not be
considered part of the conversation between the two.
The ground truth for messages in a groupchat is the view of the
groupchat server (MUC/MIX/...).
Any other archive might be incomplete (without knowing about that) and
thus is not suitable as a reference when trying to recover a full view
of a conversation history. If you want groupchat messages to be
preserved by your local server, it could do so by identifying the
message using the stanza-id of the groupchat server qualified with the
groupchat JID ("by-attribute").
> So groupchat message are ideally in the sending users MAM archive, in
> the archive of the groupchat (MUC/MIX) and in the receiving users
> archive. Therefore, they could have three elements when
> arriving at their destination.
You can have as many as you want. Still as a client developer I'm
happily going to ignore them. I doubt any client developer wants to
create the complexity of building and synchronizing a message history
from multiple archives, so one has to decide for one and it only makes
sense to use the ground truth.
> Even in your design, you need to know how to select the stanza-id you
> will store in your local store based on the 'by' attribute's value.
Technically, I wouldn't need the by-attribute if I had certainty that
my server wouldn't want to add its own archive id (which they typically
don't, but could). However, when saying I don't need the by-attribute,
I was referring to a by-attribute when referencing the message. Because
the original value of the by-attribute of the stanza-id of a message is
not even preserved in my local state (as I pointed out).
> That is where, I believe, we are on the same page. It's not rocket
> science. The hard part, which is maybe already solved, is, if the
> MUC(/MIX) stanza-id by attribute is r...@muc.example.org or
> muc.example.org. But that is probably for MAM to specify?
That's actually well-defined in XEP-0313 since 2017 [1] and as far as I
know, all client and server implementations (that support MAM using the
mam:2 namespace) get this done properly.
>
> I think the only thing we really are not on the same page is if a
> reference should be fully qualified, i.e., the tuple of (id, by), or
> not. And I would prefer explicit over implicit here.
As a client developer, even if you would require me to explicitly put
the by-attribute with every message reference, I would:
- When sending a message reference: recover the by-attribute from the
implicit value that I know it must've had to be stored as such id
(sender id or archive id).
- When receiving a message reference: Ignore any "wrong" by-attribute
in message references and just take the value that I implicitly know
must've been used when referencing (following Postel's law).
This would turn the by-attribute in a message reference into entirely
useless boilerplate that is generated out of thin air by the sender and
ignored by the recipient.
Marvin
[1] https://xmpp.org/extensions/xep-0313.html#archives_id
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
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.
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 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: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
On 22/02/2023 14.14, Marvin W wrote: Hi Flow, Hi Marvin, As it stands today, every message ideally has no more than two IDs: That is where we already think different. The more archives messages are contained in, the higher the chances are that they are preserved and recoverable. Which is usually a good thing. So groupchat message are ideally in the sending users MAM archive, in the archive of the groupchat (MUC/MIX) and in the receiving users archive. Therefore, they could have three elements when arriving at their destination. The only reason why we need the second ID is that archives can't be sure that all messages they will store have a globally unique id assigned by their senders, otherwise the archive could just have used the sender's id. Its fragile, at best, to build an archive that depends on external provided IDs for its content. As a client developer, these are the only two IDs I'll store about incoming (and outgoing, though I will only learn the archive id later) messages. Even if you add a ton of other stanza-id's I'll just ignore them. And that's exactly what we would want developers to do to ensure they do it right. So the question is not to infer the by-attribute (because there is no by-attribute in my local store). Even in your design, you need to know how to select the stanza-id you will store in your local store based on the 'by' attribute's value. The question is only which of the two id's I use for what purpose. For MAM or reflection matching, it's obvious that the archive id or the sender id is to be used, respectively. And for message referencing, it depends on the message type (groupchats use archive id, direct chats use sender id). That is where, I believe, we are on the same page. It's not rocket science. The hard part, which is maybe already solved, is, if the MUC(/MIX) stanza-id by attribute is r...@muc.example.org or muc.example.org. But that is probably for MAM to specify? Then it is easy: If you talk over a MUC you use the that was added by the MUC. Same for MIX. And in 1:1 chats you use the senders . I think the only thing we really are not on the same page is if a reference should be fully qualified, i.e., the tuple of (id, by), or not. And I would prefer explicit over implicit here. - Flow ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
> > There is a very obvious solution to this which everyone seems to be > > overlooking: we need a new element with a guaranteed unique, non-spoofed > > UUID; should a server feel the need to do bad things, it can set the > > 'spoofed' attribute to true and then clients can act accordingly. > what entity would set that element? the sending client? the server of that > client? the server of the receiving client? It was meant to be a joke about the number of stanza id mechanisms - clearly, the solution is another stanza id mechanism! (I'd hoped the 'spoofed' attribute made it obvious I wasn't serious.) 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. 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 - both the client and server can use the id for referencing (servers can still use their own internal ids for indexing and such, but the 'long' id is for all public-facing referencing), and then there's no need for the client to check which id the server gave the stanza (it's the same.) XEP-0359 attempts to do exactly this, but it only works dependably if everyone uses it, and legacy clients don't/can't. If a server does spoof ids for malicious purposes, there is no protection against this (without resorting to cryptographic signatures, which brings its own difficulties) and no amount of additional ids would help (it could spoof those too.) XMPP 2.0 will solve all of these problems, of course. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
> There is a very obvious solution to this which everyone seems to be > overlooking: we need a new element with a guaranteed unique, non-spoofed > UUID; should a server feel the need to do bad things, it can set the > 'spoofed' attribute to true and then clients can act accordingly. what entity would set that element? the sending client? the server of that client? the server of the receiving client? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
Hi Flow, As it stands today, every message ideally has no more than two IDs: - The sender assigned id (origin-id or message's id-attribute) which is required so that senders can be assured that the message is the one they sent when they fetch them from the archive or get reflected from MUCs, receive errors about it and so on. - The archive assigned id (stanza-id with by-attribute set to the archive, that is the MUC in groupchat messages and the user's own bare JID for direct chat messages). The only reason why we need the second ID is that archives can't be sure that all messages they will store have a globally unique id assigned by their senders, otherwise the archive could just have used the sender's id. As a client developer, these are the only two IDs I'll store about incoming (and outgoing, though I will only learn the archive id later) messages. Even if you add a ton of other stanza-id's I'll just ignore them. And that's exactly what we would want developers to do to ensure they do it right. So the question is not to infer the by-attribute (because there is no by-attribute in my local store). The question is only which of the two id's I use for what purpose. For MAM or reflection matching, it's obvious that the archive id or the sender id is to be used, respectively. And for message referencing, it depends on the message type (groupchats use archive id, direct chats use sender id). While having acknowledgment messages from the sender's server that tell the sender the assigned archive id would indeed be nice to have, adding that ID to the outgoing message means that now there is another ID at the recipient. If that ID is meant to be used for referencing later and clients need to handle it on top of the previous two, this only adds even more potential for confusion for client developers - and I don't see the benefit that would justify such additional potential of confusion and mistakes. The only usecase where I see fit and good reason for a by-attribute in a reference, is when one wants to reference a message from the archive of another conversation (e.g. when forwarding a message from one MUC to another). In that case though, one probably wants to make the fact that this reference is pointing outside the current context more explicit than just having a by-attribute that seems to be invalid in the current context. Marvin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
There is a very obvious solution to this which everyone seems to be overlooking: we need a new element with a guaranteed unique, non-spoofed UUID; should a server feel the need to do bad things, it can set the 'spoofed' attribute to true and then clients can act accordingly. Something like: Or in the case of server interference: Simple The informational guidance XEP is a good idea too. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
Hi, I just want to briefly mention that I agree with Marvin here. The rules in XEP-0461 (Message Replies) and XEP-0444 (Message Reactions) are good. We don’t need to make the stanza-id XEP more complicated. We should however outsource the two-three paragraphs on what ID to use into it’s own XEP. (Marvin suggested this; I'm just repeating this because I agree) If fastening had security issues (I didn’t check) I don’t think it matters anymore because we are in the process of phasing that out. cheers Daniel On Tue, Feb 21, 2023 at 9:20 PM Marvin W wrote: > > Hi, > > This is feedback for the latest PR to XEP-0359. > > > The value of origin-id is spoofable and hence MUST not be used when > referencing other stanzas. > > - This doesn't explain at all what "spoofable" means. > - origin-id's are supposed to be unique only within the scope of the > origin. In semi-anonymous MUCs, the origin is typically unknown, thus > the uniqueness scope is unknown and the origin-id can't be assumed > unique at all. > - I do think that using origin-id to reference other stanzas is still > possible with reasonable security for several usecases in "trusted" > conversations (e.g. direct chats, non-anonymous MUCs). > > > The value tuple of 'id' and 'by' of the stanza-id element is > unspoofable iff all involved implementations follow the requirements of > this specification. > > - This doesn't explain at all what "unspoofable" means. > - The sender or any relay of a message can insert or modify stanza-id's > with the by-attribute set to a third-party, as long as that message is > not routed through that third-party afterwards. > - A user's server can modify the stanza-id of MUC messages sent to > that user. > - The sender can add stanza-id of a third-party server. Depending on > the usecase (for example semi-anonymous MUC messages), the recipient > will be unable to decide if the message was actually routed through > that server or not. > - All involved implementations include the sender and all entities in- > between, i.e. everyone that could spoof. Saying that something is > unspoofable just because the specification forbids everyone involved to > spoof sounds superfluous to me. > > > The element can be used to reference another > stanza. > > I don't think it's a good idea to add this element, for a lot of > reasons. > > This XEP itself is (even if it was in Deferred state) widely > implemented. Adding something entirely new to it instead of in a new > XEP should be well-reasoned IMO. > > This newly added element is not within the self-imposed usecase of the > XEP (as is written in the abstract and introduction). > > As I wrote in my previous message [1], I don't think requiring a by- > attribute is a good idea or even adding any value when referencing > messages. > > For all practical usecases, there will always only be a single by- > attribute that is valid (the bare JID of the MUC [2]) and for every > incoming message from a MUC, that value is already known implicitly. If > our current documentation/specification leads to people incorrectly > accepting stanza-id's with other values for the by-attribute, that's an > issue on it's own which may not even be solved by adding this > attribute. > > In non-MUC messages, there generally is no stanza-id that could be used > for referencing a message in a way that can be understood by the > counterparties, so this newly proposed element would not even work for > referencing outside MUCs, making every XEP that would adopt this > element no longer work outside MUCs. > > For MAM purposes, the stanza-id is used inside data forms, where using > this element is not really feasible. > > > > > All in all, I get the feeling this is a rushed change caused by > incorrect wording in XEP-0422 that caused misunderstanding while > creating XEP-0424. As we're currently in the process of deprecating > XEP-0422 and removing it from XEP-0424, we can take the opportunity to > also fix XEP-0424 to use the correct stanza-id instead. > > Adding hints/notes to XEP-0359 to ensure this doesn't happen again is > probably a good idea though (even if I don't think the current wording > is good), as is to create a new informational XEP that describes the > rules for referencing messages in direct chats and groupchats, > including developer notes on what to take care of to implement this > correctly and spoof-safe. > > If there is consensus that the latter is a good idea, I can create a > first draft for this. > > Marvin > > > [1] > https://mail.jabber.org/pipermail/standards/2023-February/039171.html > [2] While I'm talking about MUCs exclusively here, I'd assume the same > to apply for any other groupchat system we may come up with that works > based on a single forwarding relay (MIX, etc) > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org >
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
On 22/02/2023 12.35, Florian Schmaus wrote: With the current state of affairs, you only need to use origin-id in 1:1 chats. Foosball tonight? thumbs-up I believe the last above should be thumbs-up which demonstrates how tricky this is. - Flow ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
It appears there are two possible design options A) do not state 'by' when referencing a stanza and provide rules how the 'by' value can be inferred depending on the usage context B) explicitly state the 'by' attribute and provide rules that allow to determine if the used 'by' attribute when referencing a stanza is valid I think you lean towards A) while I would argue that it is better to be explicit in such a sensitive context and go with B). I agree that origin-id can be used relatively safely in certain circumstance. However, past experience has shown that it is easy to misuse origin-id. I think, for example, urn:xmpp:fasten:0 used it exclusively without any security considerations. With the current state of affairs, you only need to use origin-id in 1:1 chats. Foosball tonight? thumbs-up I see that this would be disallowed by the current state of PR 1272. But the current wording could be relaxed. However, people have long been complaining about origin-id and its perceived uselessness. Additionally, there has been the idea of the client's server acknowledging outgoing messages with some metadata about the message. If he had this, then we would no need to use origin-id in the case above. Because then we had Foosball tonight? User b...@exmaple.org when then receive Foosball tonight? and could thumbs-up But we don't have that nice thing. So I am probably convinced, due the lack of alternatives, that relaxing the wording regarding origin-id's usage is the only viable option at the moment. I still prefer the design approach B) above, though. - Flow ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
+1 for an informational xep detailing how to reference messages in various scenarios (muc, 1:1 etc.). Am Dienstag, 21. Februar 2023, 21:17:23 CET schrieb Marvin W: > Hi, > > This is feedback for the latest PR to XEP-0359. > > > The value of origin-id is spoofable and hence MUST not be used when > > referencing other stanzas. > > - This doesn't explain at all what "spoofable" means. > - origin-id's are supposed to be unique only within the scope of the > origin. In semi-anonymous MUCs, the origin is typically unknown, thus > the uniqueness scope is unknown and the origin-id can't be assumed > unique at all. > - I do think that using origin-id to reference other stanzas is still > possible with reasonable security for several usecases in "trusted" > conversations (e.g. direct chats, non-anonymous MUCs). > > > The value tuple of 'id' and 'by' of the stanza-id element is > > unspoofable iff all involved implementations follow the requirements of > this specification. > > - This doesn't explain at all what "unspoofable" means. > - The sender or any relay of a message can insert or modify stanza-id's > with the by-attribute set to a third-party, as long as that message is > not routed through that third-party afterwards. > - A user's server can modify the stanza-id of MUC messages sent to > that user. > - The sender can add stanza-id of a third-party server. Depending on > the usecase (for example semi-anonymous MUC messages), the recipient > will be unable to decide if the message was actually routed through > that server or not. > - All involved implementations include the sender and all entities in- > between, i.e. everyone that could spoof. Saying that something is > unspoofable just because the specification forbids everyone involved to > spoof sounds superfluous to me. > > > The element can be used to reference another > > stanza. > > I don't think it's a good idea to add this element, for a lot of > reasons. > > This XEP itself is (even if it was in Deferred state) widely > implemented. Adding something entirely new to it instead of in a new > XEP should be well-reasoned IMO. > > This newly added element is not within the self-imposed usecase of the > XEP (as is written in the abstract and introduction). > > As I wrote in my previous message [1], I don't think requiring a by- > attribute is a good idea or even adding any value when referencing > messages. > > For all practical usecases, there will always only be a single by- > attribute that is valid (the bare JID of the MUC [2]) and for every > incoming message from a MUC, that value is already known implicitly. If > our current documentation/specification leads to people incorrectly > accepting stanza-id's with other values for the by-attribute, that's an > issue on it's own which may not even be solved by adding this > attribute. > > In non-MUC messages, there generally is no stanza-id that could be used > for referencing a message in a way that can be understood by the > counterparties, so this newly proposed element would not even work for > referencing outside MUCs, making every XEP that would adopt this > element no longer work outside MUCs. > > For MAM purposes, the stanza-id is used inside data forms, where using > this element is not really feasible. > > > > > All in all, I get the feeling this is a rushed change caused by > incorrect wording in XEP-0422 that caused misunderstanding while > creating XEP-0424. As we're currently in the process of deprecating > XEP-0422 and removing it from XEP-0424, we can take the opportunity to > also fix XEP-0424 to use the correct stanza-id instead. > > Adding hints/notes to XEP-0359 to ensure this doesn't happen again is > probably a good idea though (even if I don't think the current wording > is good), as is to create a new informational XEP that describes the > rules for referencing messages in direct chats and groupchats, > including developer notes on what to take care of to implement this > correctly and spoof-safe. > > If there is consensus that the latter is a good idea, I can create a > first draft for this. > > Marvin > > > [1] > https://mail.jabber.org/pipermail/standards/2023-February/039171.html > [2] While I'm talking about MUCs exclusively here, I'd assume the same > to apply for any other groupchat system we may come up with that works > based on a single forwarding relay (MIX, etc) > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
Hi, This is feedback for the latest PR to XEP-0359. > The value of origin-id is spoofable and hence MUST not be used when referencing other stanzas. - This doesn't explain at all what "spoofable" means. - origin-id's are supposed to be unique only within the scope of the origin. In semi-anonymous MUCs, the origin is typically unknown, thus the uniqueness scope is unknown and the origin-id can't be assumed unique at all. - I do think that using origin-id to reference other stanzas is still possible with reasonable security for several usecases in "trusted" conversations (e.g. direct chats, non-anonymous MUCs). > The value tuple of 'id' and 'by' of the stanza-id element is unspoofable iff all involved implementations follow the requirements of this specification. - This doesn't explain at all what "unspoofable" means. - The sender or any relay of a message can insert or modify stanza-id's with the by-attribute set to a third-party, as long as that message is not routed through that third-party afterwards. - A user's server can modify the stanza-id of MUC messages sent to that user. - The sender can add stanza-id of a third-party server. Depending on the usecase (for example semi-anonymous MUC messages), the recipient will be unable to decide if the message was actually routed through that server or not. - All involved implementations include the sender and all entities in- between, i.e. everyone that could spoof. Saying that something is unspoofable just because the specification forbids everyone involved to spoof sounds superfluous to me. > The element can be used to reference another stanza. I don't think it's a good idea to add this element, for a lot of reasons. This XEP itself is (even if it was in Deferred state) widely implemented. Adding something entirely new to it instead of in a new XEP should be well-reasoned IMO. This newly added element is not within the self-imposed usecase of the XEP (as is written in the abstract and introduction). As I wrote in my previous message [1], I don't think requiring a by- attribute is a good idea or even adding any value when referencing messages. For all practical usecases, there will always only be a single by- attribute that is valid (the bare JID of the MUC [2]) and for every incoming message from a MUC, that value is already known implicitly. If our current documentation/specification leads to people incorrectly accepting stanza-id's with other values for the by-attribute, that's an issue on it's own which may not even be solved by adding this attribute. In non-MUC messages, there generally is no stanza-id that could be used for referencing a message in a way that can be understood by the counterparties, so this newly proposed element would not even work for referencing outside MUCs, making every XEP that would adopt this element no longer work outside MUCs. For MAM purposes, the stanza-id is used inside data forms, where using this element is not really feasible. All in all, I get the feeling this is a rushed change caused by incorrect wording in XEP-0422 that caused misunderstanding while creating XEP-0424. As we're currently in the process of deprecating XEP-0422 and removing it from XEP-0424, we can take the opportunity to also fix XEP-0424 to use the correct stanza-id instead. Adding hints/notes to XEP-0359 to ensure this doesn't happen again is probably a good idea though (even if I don't think the current wording is good), as is to create a new informational XEP that describes the rules for referencing messages in direct chats and groupchats, including developer notes on what to take care of to implement this correctly and spoof-safe. If there is consensus that the latter is a good idea, I can create a first draft for this. Marvin [1] https://mail.jabber.org/pipermail/standards/2023-February/039171.html [2] While I'm talking about MUCs exclusively here, I'd assume the same to apply for any other groupchat system we may come up with that works based on a single forwarding relay (MIX, etc) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
