XSF Discussion - 2022-05-25


  1. goffi

    hi, what's the status of https://xmpp.org/extensions/xep-0424.html ? It's in last-call which is supposed to be ended since 2022-01-04…

  2. goffi

    ping jcbrand ^

  3. Zash

    https://logs.xmpp.org/council/2022-01-05?p=h#2022-01-05-fa0ce69fd8b2d0be

  4. goffi

    Zash: Thanks. The XEP should not be updated to remove the last-call notice then?

  5. Zash

    Maybe, ask the editor?

  6. goffi

    right, I've let a note on editor@

  7. goffi

    jcbrand: any plan to update this XEP? I'm asking because I'm about to implement it.

  8. jcbrand

    goffi: AFAIK people didn't like the `<apply-to>` wrapper. It's already implemented in Converse and Gajim AFAIK. I've been meaning to study people's feedback and make adjustments but haven't found the time. Mainly because IMO it works well and I have many other things on my plate.

  9. jcbrand

    Probably one could get rid of `<apply-to>` and just have `<retract>` like we have for `<correction>` and then it might get accepted, unless there's something I forgot.

  10. goffi

    jcbrand: I see, thanks. Well I'll implement in current state, and will adapt when necessary.

  11. Andrzej

    jcbrand, XEP-0424 is also implemented in SiskinIM and BeagleIM, and it works as expected

  12. jcbrand

    Ah cool, good to know

  13. flow

    how do implementations behave is someone smuggels in an message with an origin-id that is identical the origin-id of a previous message that got retracted?

  14. flow

    how do implementations behave is someone smuggels in a message with an origin-id that is identical the origin-id of a previous message that got retracted?

  15. Zash

    abolish origin-id!

  16. Ge0rG

    halt and catch fire

  17. Andrzej

    in our case, we are accepting those, but during lookup we are looking for the newest message with matching origin-id

  18. flow

    Andrzej, so I can un-retract a message by injecting a newer message with a duplicate origin-id?

  19. Andrzej

    no, it would result in a new message

  20. Andrzej

    only further references would be related to the new message

  21. Ge0rG

    how do you treat LMC on a retracted message?

  22. Ge0rG

    semantically, a message with the same origin-id should be treated as a duplicate of the original message, except when they have different stanza-ids. So I suppose it is safe to ignore everything with a seen-before origin-id.

  23. Ge0rG

    The other part of the question is about "operator precedence" of message-modifying messages. Does LMC beat retraction? Does moderator retraction beat LMC?

  24. jcbrand

    Depends on what is received first? In any case, LMC on a retracted message is moot, since the message has been retracted

  25. Ge0rG

    jcbrand: what about: I send something obscene, the message is retracted by mods, I edit it to remove the obscenity?

  26. jcbrand

    It's already retracted, so your correction can no longer be applied

  27. jcbrand

    TBH, I'm not sure how much I've tested such edge cases, but that's what I would expect

  28. jcbrand

    i.e. retraction has precedence over corrections

  29. jcbrand

    should perhaps be mentioned in the XEP

  30. Andrzej

    I'm pretty sure that if message would be retracted in my clients, you wouldn't be able to edit it

  31. Andrzej

    I'm pretty sure that if message would be retracted in my clients, you wouldn't be able to correct it

  32. jcbrand

    No, but a cilent that doesn't support retractions could allow it

  33. flow

    I am still very skeptical to reference previous messages by origin-id, as opposed to using stanza-id, i.e. the securely combined values of the stanza-id 'by' and 'id' attribute

  34. Ge0rG

    You could race a retraction and an edit from different clients. Or just use an XML console

  35. jcbrand

    flow you don't always have the stanza-id. For example when you want to retract a message you just sent

  36. Ge0rG

    flow: let's just get rid of origin-id then, okay?

  37. Ge0rG

    jcbrand: that's a point I've tried to make for a while. I suppose you need to keep a list of in-flight messages and delay updates that reference them until they've been MAMed

  38. flow

    jcbrand, surely you can wait till you observe the messsage reflection containing the stanza-id. you want to wait for it anyways before you show it as received by the channel

  39. jcbrand

    1:1 messages don't get reflected

  40. Ge0rG

    jcbrand: that's another wart on the design of MAM

  41. jcbrand

    It's been a while, but I'm pretty sure Converse prioritizes stanza-id over oriring-id

  42. flow

    jcbrand, yeah, what Ge0rG said. but you could always query your local MAM to get the stanza-id of the message

  43. Ge0rG

    would be great to receive a carbon shell on each sent message that was put into MAM

  44. Ge0rG

    flow: that's like the worst design idea ever

  45. flow

    surely not ideal

  46. jcbrand

    Yeah, I'm not doing that

  47. flow

    in any case, I believe it is possible to use stanza-id in the MUC(/MIX) case, and the XEPs should reflect that

  48. flow

    as I wrote a while ago to standards@, using origin-id is prone to id-impersonating issues

  49. jcbrand

    origin-id should be matched with the `from` attribute

  50. jcbrand

    That's kind of obvious, no?

  51. Ge0rG

    flow: let's just get rid of origin-id then, okay?

  52. flow

    jcbrand, it isn't and afaik it's nowhere specified

  53. Ge0rG needs to put that on a key binding.

  54. jcbrand

    If you match origin-id with `from` there's no impersonation risk

  55. flow

    probably, but this should be explicitly spelled out then. I fear a lot of implementations treat origin-id as being magical by itself, when there is no authoritiy that authenticates those IDs

  56. jcbrand

    It's mentioned in the security considerations of XEP-424 https://xmpp.org/extensions/xep-0424.html#security

  57. flow

    that could be enough, since it appears to limit retractions to be send only by the "owner" of the retracted message. But I always have the 'fastening' case in mind, where anyone can react with a +1 on somebody else's message, and it's IMHO also based on origin-id

  58. jcbrand

    Retracting someone else's message is XEP-425

  59. flow

    which kinda makes it susceptible to the kind of attacks where I replace the message you just +1'ed with a different message…

  60. jcbrand

    yes, that sounds broken

  61. jcbrand

    `origin-id` works when the person doing the modification is the sender of the original message

  62. jcbrand

    `origin-id` works when the person doing the modification is always the sender of the original message

  63. jcbrand

    which is the case with retractions

  64. flow

    true, I am less concerned now, aftter discussing this

  65. flow

    true, I am less concerned now, after discussing this

  66. flow

    although, I believe the buisness rules and security considerations of xep425 could be better stated (but isn't that always the case?)

  67. jcbrand

    Is there something specific that you're missing?

  68. flow

    mostly discussion of the threats to motivate the buisness rules

  69. MattJ

    Remind me why we're still using origin-id?

  70. jcbrand

    because you don't get reflection for 1:1 chats

  71. Zash

    Okay, but why origin-id when there's the stanza@id ?

  72. jcbrand

    because you don't have that without reflection

  73. Zash

    huh? but, _you_ set that?

  74. jcbrand

    do you set your own stanza-ids when you send messages?

  75. Zash

    `<message id="THIS"/>`

  76. jcbrand

    oh sorry, that id

  77. jcbrand

    because they have no guarantee of being unique

  78. Zash

    ... when _you_ yourself set them?

  79. Zash

    and then later refer to your own messages (in the context of XEP-0424)

  80. jcbrand

    I see what you're getting at, but I don't see how this is better than using origin-id, particularly because clients (devs) have been conditioned to not trust the id to be unique

  81. MattJ

    Right, is it wrong to question that conditioning?

  82. MattJ

    Devs are also complaining about how many ids we have

  83. MattJ

    And yes, it is getting a bit silly

  84. jcbrand

    Converse in any case makes the origin-id and the id the same, like Conversations

  85. MattJ

    The number of times I've had "oh no, when I said 'the id of the stanza I meant...' conversations with devs"

  86. Zash

    Every message needs at least 5 ids and 3 timestamps!

  87. jcbrand

    Obviously unique ids would have been ideal, but my impression was that that ship has sailed

  88. MattJ

    The number of times I've had "oh no, when I said 'the id of the stanza' I meant..." conversations with devs

  89. MattJ

    I don't think it has, but people continue to push the ship further out, and I like to speak up when I see that happening. I and a number of other people really think that origin-id should be deprecated.

  90. MattJ

    Not used in more and more specs

  91. jcbrand

    meh 🙂

  92. jcbrand

    I really don't see the harm here

  93. Zash

    ```xml <message id='fa137ce375c641e5808cbcff88770973' type='groupchat' xml:lang='en' from='xsf@muc.xmpp.org/MattJ'> <origin-id id='fa137ce375c641e5808cbcff88770973' xmlns='urn:xmpp:sid:0'/> <body>And yes, it is getting a bit silly</body> <active xmlns='http://jabber.org/protocol/chatstates'/> <occupant-id id='Im3knKDDFlUHyEv8Cj9d/Vx/KnTelRKocoOQSB3SncM=' xmlns='urn:xmpp:occupant-id:0'/> <stanza-id id='2022-05-25-c7615d7b398f5235' xmlns='urn:xmpp:sid:0' by='xsf@muc.xmpp.org'/> <delay xmlns='urn:xmpp:delay' stamp='2022-05-25T12:31:52Z' from='xsf@muc.xmpp.org'/> </message> ``` Count the number of IDs!

  94. jcbrand

    It's more explicit than relying on an idea where there is no guarantee of uniqueness

  95. Kev

    If we assume that stanza@id is stable now, origin-id gives us nothing, does it?

  96. MattJ

    There's also no guarantee that either 'id' or 'origin-id' even exist, so you still have to handle that case either way

  97. jcbrand

    it's not stable, there are still clients that don't have unique stanza@id

  98. Zash

    Kev, in-message promise that the id is unique?

  99. Zash

    So it could just be `<origin-id/>` without the id

  100. jcbrand

    MattJ: XEP-424 mandates origin-id, so it must be there

  101. Kev

    Ah, uniqueness between clients and sessions, right.

  102. MattJ

    jcbrand, right, so why can't it just mandate that @id is unique?

  103. mdosch

    How to know whether it's unique when you just create a random string?

  104. MattJ

    Same thing

  105. jcbrand

    I guess it can, but since that was already mandated for origin-id, it seemed simpler to just use that.

  106. Zash

    `<message id="uuid"><{I-promise}id-is-unique/></>`

  107. MattJ

    Zash, but even then you have to deal with the absence of that (e.g. if you have a legacy client on your account)

  108. MattJ

    Same as if you "mandate" origin-id

  109. jcbrand

    To me, it seems like more dev overhead. Now you have to know that there are some cases where stanza@id is unique and others where you can't rely on it being unique

  110. jcbrand

    better to just say it's not unique

  111. Kev

    That's just the same as origin-id, though, where it might be missing.

  112. Kev

    Isn't it?

  113. jcbrand

    I don't see how it's the same

  114. MattJ

    It's not more dev overhead, it's exactly the same but with additional useless syntax

  115. jcbrand

    explicit is better than implicit

  116. jcbrand

    implicit = more overhead

  117. MattJ

    So state explicitly in the XEP that any client supporting MUST use unique @id attributes

  118. jcbrand

    it's not the same IMO

  119. MattJ

    and that removes a needless dependency on a XEP that many of us want to deprecate

  120. jcbrand

    it's not explicit in the stanza in that case

  121. jcbrand

    why do you want to deprecate it?

  122. MattJ

    Because it's additional overhead, duplicated information and confusing

  123. jcbrand

    so having stanza@id sometimes being unique and sometimes not is not confusing?

  124. MattJ

    No, it should always be unique in any modern client, and we should push for that

  125. jcbrand

    yes but people us non-modern clients as well

  126. MattJ

    But adding additional syntax doesn't really help, because you still have to deal with the case where it is not unique or missing

  127. jcbrand

    > you still have to deal with the case where it is not unique I don't agree, IMO you can assume that origin-id together with `from` is always unique

  128. MattJ

    But origin-id is not always there

  129. jcbrand

    if it's missing, then that's also explicit

  130. jcbrand

    I'll have to go check, but IIRC I rely on origin-id quite a bit in Converse to dedupe messages

  131. jonas’

    jcbrand, what about an attacker? :)

  132. jcbrand

    And I think a web-client has to care much more about deduping than other clients

  133. jonas’

    someone maliciously setting origin-id to equal values

  134. jcbrand

    jonas’ If you match `from` and origin-id then attack doesn't work

  135. jonas’

    depends on the attack I suppose

  136. jcbrand

    jonas’ In any case, that would apply to stanza@id also

  137. jonas’

    exactly

  138. jonas’

    making origin-id useless

  139. jonas’

    there is no gain here, you need to be equipped to deal with duplicate or missing IDs, because clients can be legacy or malicious/buggy

  140. jonas’

    and it shouldn't break your client

  141. jcbrand

    I never said that I'm pro origin-id to prevent attacks that can happen with stanza@id

  142. jonas’

    that's not what I said either

  143. jcbrand

    The gain here is that you can safely assume that origin-id (with `from`) is unique

  144. jonas’

    I just said that there is absolutely zero gain with origin-id

  145. jonas’

    no, you can't

  146. jcbrand

    Yes you can

  147. jonas’

    no, it's remote data. You can never assume any property like uniqueness about it.

  148. MattJ

    Yeah, you can assume it is, but it might be wrong. But that's a whole other level :)

  149. jonas’

    you can work on the basis that it probably is, but you absolutely need to gracefully handle cases where it isn't. and then there is zero (0) gain of using origin-id over @id

  150. jonas’

    fair

  151. jonas’

    words!

  152. jcbrand

    I don't agree

  153. jonas’

    I finally get proper pressure values from my sensors now, so I'll tune out and bring my sensor network back up again.

  154. MattJ

    You don't agree? I could modify my client today to send <origin-id id='hello world'/> on every message

  155. jcbrand

    and then that's your problem?

  156. jcbrand

    you're not following the spec

  157. MattJ

    That depends what you're using it for

  158. jonas’

    jcbrand, if that's just MattJs problem, then why not use message@id? :)

  159. jcbrand

    sigh

  160. MattJ

    Sure I'm not following the spec, but if you're relying on every entity to follow spec behaviour, that could cause problems for you

  161. jcbrand

    because message@id is not guaranteed to be unique, so if he did that with message@id it would still be spec compliant

  162. MattJ

    It really depends what you're using it for

  163. jcbrand

    to some extent

  164. MattJ

    It wouldn't be compliant in any XEP-0424 client

  165. jcbrand

    sure, so you're retractions don't work

  166. Guus

    Failed to connect, CredSSP required by server

  167. jcbrand

    sure, so your retractions don't work

  168. MattJ

    Correct

  169. jcbrand

    actually, if you had duplicate message@id your retractions will still work if you have unique origin-id

  170. jcbrand

    that's the whole point

  171. jcbrand

    In any case, I mentioned deduping, to which no-one responded

  172. MattJ

    That doesn't make much sense, why would I have duplicate @id and unique origin-id?

  173. jcbrand

    it's not just about you, it's about the fact that other clients don't have unique message@id

  174. MattJ

    Yes, definitely not denying that some clients might not send a unique @id, or not send any @id at all

  175. Kev

    Forget all about stanza@id except on id, and only use origin-id. Best of all worlds ;D

  176. MattJ

    But you also can't deny that such clients also don't send origin-id

  177. Kev

    Forget all about stanza@id except on iq, and only use origin-id. Best of all worlds ;D

  178. MattJ

    or that some clients send unique @id and no origin-id

  179. jcbrand

    I don't deny, to me this isn't only about XEP-424

  180. MattJ

    Kev, and then error tracking becomes horrible

  181. Kev

    Note the ;D :)

  182. MattJ

    Someone might take you seriously :P

  183. jcbrand

    It's about the fact that I use origin-id to dedupe

  184. jcbrand

    regardless of XEP-424

  185. Kev

    > Someone might take you seriously :P Not in my experience.

  186. MattJ

    jcbrand, I understand that. And your mention of that wasn't ignored... all these arguments apply to de-dupe as well

  187. jcbrand

    And personally I'm not that interested in making even more complicated deduping rules because people want to remove origin-id and then have message@id be guaranteed unique in some cases but not in others

  188. MattJ

    Note that it's not just about removing origin-id, it's not like it's universally sent today

  189. jonas’

    ok, can someone please load a module on this MUC server which sets origin-id to hello world for all messages? kthxbai

  190. MattJ

    So the point is that your de-dupe today is breaking with clients that don't send unique @id

  191. MattJ

    (I assume)

  192. MattJ

    It won't break if they send unique @id, I assume

  193. jcbrand

    jonas’ Converse gives priority to stanza-id

  194. MattJ

    The presence of origin-id has no effect on the outcome

  195. jonas’

    I've got an idea

  196. jcbrand

    MattJ: It has an effect in the sense that I can't know if someone's client sends a unique @id or not

  197. jcbrand

    except for certain edge cases like when a retraction is included

  198. jonas’

    modify '359 to say: If the `id` attribute of `<origin-id/>` is empty, it MUST be assumed to be equal to the `id` attribute on the containing stanza.

  199. jonas’

    modify '359 to say: If the `id` attribute of `<origin-id/>` is empty, it MUST be assumed to be equal to the `id` attribute on the containing stanza and the sending entity MUST adhere to the same rules for that ID as it would have for `<origin-id/>`.

  200. MattJ

    😣

  201. MattJ

    That helps with the "too many ids" confusion, but it's still... meh. Now we have to send this tag in every message for the rest of eternity?

  202. jonas’

    nah, we'll wait until most people have forgotten that it exists and just use @id directly and then drop it ;)

  203. Zash

    XMPP 2.0 can simply mandate that the id be unique on pain of ~DEATH~ stream:error

  204. jcbrand

    I have to leave

  205. MattJ

    jcbrand, you said origin-id tells you if the stanza id is unique. What do you do with this information?

  206. Zash

    Time to dig up the idea of IDs being based on a (stream-id, stanza-counter) tuple?

  207. MattJ

    Okay, later :)

  208. jcbrand

    MattJ use it to dedupe

  209. Daniel

    > XMPP 2.0 can simply mandate that the id be unique on pain of ~DEATH~ stream:error Unique and sequential UUIDv6

  210. MattJ

    and if it's not unique, no de-dupe happens?

  211. jcbrand

    I have other heuristics

  212. MattJ

    *if it may not be unique

  213. jcbrand

    but nothing as nice as having a unique id

  214. Zash

    Daniel, the time+random one? mmmmmmmmmmmmm

  215. Zash

    I just wish it was more compact

  216. jcbrand

    ok, bye, I'll be back later

  217. Kev

    Amusingly I've been looking at stuff recently where guaranteed-unique IDs are a problem and I need to get rid of them :D

  218. MattJ

    See you!

  219. Seve

    https://thehackernews.com/2022/05/new-zoom-flaws-could-let-attackers-hack.html?m=1

  220. moparisthebest

    Seve, sorry we already discussed that yesterday :D

  221. Seve

    Guessed so.. haha

  222. Zash

    Do you want to know more? https://logs.xmpp.org/xsf/2022-05-24?p=h#2022-05-24-7f462f13fbf0be1b

  223. moparisthebest

    it's a (unpatched) gloox bug, maintainer hasn't responded yet, 2 expat bugs, and an (unpatched, but may be mitigated by the expat fixes) ejabberd bug

  224. moparisthebest

    and, a (presumably novel) general XMPP attack we now need to watch out for

  225. jonas’

    what general xmpp attack?

  226. Zash

    HACK

  227. moparisthebest

    'stanza smuggling' to steal their name, where the server passes along 1 stanza that a client interprets as more-than-1

  228. jonas’

    ah

  229. jonas’

    I see I should've shouted louder when that happened in aioxmpp :)

  230. moparisthebest

    crazy thought here, what if XMPP 2.0 introduced framing, ie "this next stanza is X bytes"

  231. Kev

    Interestingly, if servers cared about validating things in jabber:(client|server), this wouldn't happen. normative schemas anyone? :)

  232. Kev

    > crazy thought here, what if XMPP 2.0 introduced framing, ie "this next stanza is X bytes" I struggle to produce an argument against it.

  233. jonas’

    please no normative schemas

  234. moparisthebest

    then servers+clients could read X more bytes, parse it to exactly 1 stanza, and if it parsed to more, hack, throw it away, stream error

  235. jonas’

    moparisthebest, that requires to know the length ahead-of-time when sending

  236. moparisthebest

    right, which since we all agree on stanza size limits you must know anyway

  237. Kev

    It would make XML parsing in general quite a lot easier for clients and servers.

  238. jonas’

    well you could also just try ;)

  239. jonas’

    (and see if your peer kills you for it)

  240. Kev

    (Or, at least, in I think all the implementations I've worked with it would have reduced some complexity)

  241. moparisthebest

    the only argument for streaming stanzas of unknown-length is malicious https://www.moparisthebest.com/eatxmempp-cve-2021-32918/

  242. jonas’

    moparisthebest, no, I think arguments can be had which are not malicious, but likely not in federated networks

  243. jonas’

    (because generic XMPP software will suffer from stuff like eatxmempp indeed)

  244. moparisthebest

    then I don't care, they can use XMPP 1.0, or likely their own variant like whatsapp does

  245. emus

    I saw that has been a hot discussion. But could someone volunteer to summarize the issue with Zoom for me? On a rather general level, as I lag most knowledge :-/ (no troll)

  246. moparisthebest

    > it's a (unpatched) gloox bug, maintainer hasn't responded yet, 2 expat bugs, and an (unpatched, but may be mitigated by the expat fixes) ejabberd bug > and, a (presumably novel) general XMPP attack we now need to watch out for > 'stanza smuggling' to steal their name, where the server passes along 1 stanza that a client interprets as more-than-1 emus I *think* that's a fair summary ^

  247. moparisthebest

    the reason this was catastrophic in zoom is the second stanza smuggled in told the client to download a binary and execute it, don't think any XMPP things on the public federated network do anything that stupid

  248. emus

    So, it was not know, but also no practice out there in the wild XMPP?

  249. emus

    but thanks for responding!

  250. moparisthebest

    not really known before, but apparantly jonas’ experienced similar in aioxmpp just didn't spread it around :D

  251. moparisthebest

    you could pull off the same hack right now on a user of Renga if they were connected to a server without a patched expat

  252. moparisthebest

    "hi this is your admin" - from admin@yourserver

  253. qy

    can zoom federate?

  254. moparisthebest

    seriously doubt it

  255. emus

    moparisthebest: thanks

  256. TheCoffeMaker

    jonas’, ping sent u a message regarding a ping account for observe.jabber.network

  257. jonas’

    TheCoffeMaker, ah yes, I meant to reply to that

  258. TheCoffeMaker

    jonas’, no problem!