XSF Discussion - 2020-04-21


  1. flow

    pep.> I find the current experimental XEP updating flow a bit weird. Yep, it is not ideal that some big changes to experimental XEPs get merged without asking for feedback first

  2. jonas’

    why?

  3. jonas’

    experimental XEPs shouldn’t be deployed either way :>

  4. flow

    doesn't matter, gathering feedback prior merge is still sensible as it potentially improves the XEP while avoiding frequent namespace bumps

  5. jonas’

    versions are cheap if nothing is deployed :)

  6. flow

    no they are not

  7. Neustradamus

    There is a problem to with inbox folder, there are not redirection to official XEPs...

  8. jonas’

    Neustradamus, Thanks! Now make a PR to fix it.

  9. flow

    I also question the sentiment that experimental XEPs shouldn't get deployed, at least for certain definitions of deployed. you obviously want to have them deployed in experimental setups

  10. Neustradamus

    It is not up-to-date but I have listed here: https://github.com/xsf/xmpp.org/issues/421

  11. jonas’

    Neustradamus, that’s an issue, not a PR.

  12. Neustradamus

    jonas’: I have said, I have listed ;)

  13. jonas’

    and I said we need a PR to fix it

  14. jonas’

    not an issue

  15. jonas’

    issues are worthless if there’s no one working on it.

  16. pep.

    flow: I wasn't talking about namespace bumps, even though I disagree about jonas’' “nothing gets deployed”, it's really all just a waste of time for editors not to leave a short period of time here for authors to hear/incorporate feedback :(

  17. marc

    MattJ: are you interested in the 401 discussion?

  18. Zash

    https://xmpp.org/extensions/xep-0191.html#example-9 This error you should get when you send a stanza to a JID you yourself have blocked, it should have an error/@by attribute of the account, right?

  19. flow

    pep., I know that you didn't talk about namespace bump, I just mentioned it as consequence of this. To be fair, even if editors would keep PRs open for longer period of time to gather feedback, your process does not make it easy to review the proposed changes

  20. flow

    Zash, I think there is no reason it couldn't have the 'by' attribute. I haven't read the spec if it is required thoguh

  21. flow

    Zash, I think there is no reason it couldn't have the 'by' attribute. I haven't read the spec if it is required though

  22. pep.

    flow: agreed about the reviews

  23. flow

    pep., \o/ ;)

  24. MattJ

    marc [11:21]: > MattJ: are you interested in the 401 discussion? For sure!

  25. pep.

    if that's a public discussion I'll definitely read it :)

  26. eta

    can you use chat markers in MUC?

  27. eta

    I tried and the clients I'm using don't seem to care about the markers

  28. marc

    MattJ: didn't you get the invitation?

  29. MattJ

    Maybe, MUC invitation?

  30. Zash

    I tried sending you one too

  31. MattJ

    Not sure if yaxim supports them

  32. MattJ

    Or maybe my firewall rules

  33. Zash

    Ge0rG, fix it

  34. pep.

    eta: I think it's done in some conditions. I merged MattJ 's PR re 0333 in MUC. waiting for iteam to pull the updates

  35. marc

    MattJ: I tried to reinvite you :-/

  36. eta

    pep., oh right, apparently you might need to include the 'id' field in the <displayed/> element

  37. eta

    that's odd

  38. eta

    oh wait, nvm, you always do that

  39. eta

    pep., is there a link to that PR?

  40. pep.

    eta, https://xmpp.org/extensions/xep-0333.html#appendix-revs it's live now :)

  41. pep.

    https://github.com/xsf/xeps/pull/927 PR

  42. eta

    pep., oh, you need unique and stable stanza IDs

  43. Ge0rG

    Zash: fix what? MattJ's broken default firewall?

  44. Ge0rG

    I'm pretty sure I reviewed the rules and highlighted that they break MUC invitation an eternity ago

  45. MattJ

    TIL `make preview` in xsf/xeps

  46. rion

    do we have unicode symbol for muc topic?

  47. Ge0rG

    rion: you can sponsor one

  48. Ge0rG

    👥🗩

  49. Yagiza

    Just read latest version of XEP-0333.

  50. rion

    sponsor? no idea how.

  51. Ge0rG

    rion: https://wiki.xmpp.org/web/Adopt-a-Character

  52. pep.

    I don't think that's what he asked

  53. Ge0rG

    there should be a way to pay the unicode consortium to add *new* characters.

  54. Daniel

    I'm sure there is

  55. pep.

    bribery?

  56. pep.

    lobbying?

  57. Daniel

    Little bit of both

  58. Ge0rG

    nah, they demand proof of importance or somesuch

  59. pep.

    Ge0rG, "My brand is very important!"

  60. Ge0rG

    kinda-sorta

  61. Yagiza

    It seems all the mentions about message type are removed. But section 8.1 says that "Only Messages that can be displayed in a chat SHOULD be markable".

  62. Yagiza

    Does that mean that I should not set "type" attribute for a chat marker Message and if my client displays Normal message not in a chat but in a separate windows, I should no make Normal messages markable?

  63. Blue

    That's actually a very sad thing about proof of importance. The wikipedia is into removing the article in russian about fediverse due to the lack of importance

  64. MattJ

    Yagiza, I'm not sure I understand. I made the last update to the XEP, I didn't remove anything, I only added.

  65. Yagiza

    MattJ, I know. It seems that part was removed before your last update.

  66. MattJ

    Yagiza, I don't see any such changes

  67. MattJ

    It looks like it has all been typo fixes and state changes since 2013

  68. MattJ

    Yagiza, hmm. Are you maybe confusing it with XEP-0085: Chat State Notifications?

  69. MattJ

    That one discusses types

  70. SamWhited

    Quick question to get an overview of what people here think: When writing https://xmpp.org/extensions/inbox/password-storage.html I specified that SCRAM should be used because RFC 6120 mandates it anyways. However, I tend to think it would be better to start phasing it out and just using PLAIN, so maybe it's best if I don't add requirements for SCRAM-SHA-256. What do people think?

  71. Holger

    I'm all for it but am not sure you'll easily get a consensus on that 😉

  72. jonas’

    SamWhited, I think this should be an RFC

  73. SamWhited

    The main reasons I consider PLAIN to be a better option are that it makes the password hash more agile (it's easy to update it to use a new hash, or a higher workfactor on login), it makes it so that server policy can contain password requirements like a minimum length and have a blacklist of common passwords (eg. it can reject "passw0rd", etc.)

  74. jonas’

    not a XEP

  75. Zash

    Can an Informational XEP even make such demands?

  76. jonas’

    it’s not really specific to XMPP, is it?

  77. SamWhited

    jonas’: I disagree, those are too hard for us to update regularly.

  78. SamWhited

    Zash: it's just recommendations. I did feel that RFC 2119 language was important to distinguish the importance of various bits of the XEP, but at the end of the day it is informational

  79. Zash

    > start phasing [SCRAM] out and just using PLAIN Strongly disagree

  80. Holger

    One downside is that hash recalculation is expensive so more prone to DoS.

  81. Zash

    I'd rather get rid of PLAIN and use only SCRAM

  82. SamWhited

    Zash: why? As far as I can tell PLAIN is much better in all the ways that really matter (eg. in terms of common attacks that can be prevented). The property of not sending the actual password to the server is kind of nice, but also that isn't where passwords are normally attacked

  83. SamWhited

    Holger: that's a fair point, but then again web servers always seem to manage to do it okay

  84. Zash

    So strong is my disagreement that I can't put it into words

  85. Zash

    SamWhited, you mean we should switch to OAuth?

  86. Yagiza

    MattJ, yes, maybe

  87. Ge0rG

    Sending passwords to the server requires storing them on the client though, and this is a very common stealing vector.

  88. SamWhited

    Ge0rG: also a good point, adding that to my pros/cons list

  89. Zash

    "The web does it" is not an argument that's going to work on me.

  90. Zash

    Not unless it's "bring back XHTML-IM"

  91. Ge0rG

    OTOH, you need to store _something_ on the client, and that will be usable to login to xmpp. However, it won't be usable to login into your Gmail

  92. jonas’

    but surely everyone uses separate credentials for all the things!!k

  93. Zash

    SCRAM lets you store some magic hash on the client and login with that.

  94. SamWhited

    It's not an argument for "we should do it because we need to do what the web does", it's a counterpoint that it doesn't seem to lead to DOS' in practice

  95. Zash

    Without doing the *expensive* PBKDF2 operation again

  96. Zash

    And without the server doing that either

  97. Ge0rG

    Mmmhmmm! Magic hash!

  98. Zash

    Just like 5 hash operations and some XOR magic and you're golden

  99. Zash

    Even if you set the iteration count to a larger number than I'll bother typing out

  100. SamWhited

    So rehashing may be expensive, and that's sad, but it's not a security issue so I'm not sure how much I care (unless there were literally no other common security issues to worry about). Requiring plaintext on the client is one, so I guess the question is: is that more common than not being able to set a password policy on the server or passwords being broken because SCRAm provides no agility for hashes and work factors

  101. SamWhited

    My guess is that the latter are much more common. In particular, letting servers define a blacklist (no "passw0rd", "aaaa", a dump downloaded from a recent <common web service> breach, etc.) is probably the biggest single way people break into accounts

  102. Zash

    This is why we need SASL2, which was supposed to provide credential upgrades and the like.

  103. SamWhited

    Yah, if we could at least get that problem solved it would be good. Not being able to set server policy seems much more dangerous than anything else though, and I think that's just not solvable with SCRAM.

  104. SamWhited

    I suppose I could mandate that clients all have a policy for disallowing common passwords and what not ("mandate" meaning "if you're following this XEPs advice, do this please", of course)

  105. SamWhited

    But that feels wrong and less likely to be widely adopted.

  106. Zash

    It's not solvable with SCRAM doesn't mean SCRAM needs to go.

  107. Zash

    It's not like you send SCRAM hashes from the client to register or change password, all that's by sending the plain text already.

  108. SamWhited

    Ahh, that's a good point that I was stupidly forgetting.

  109. SamWhited

    Okay, so maybe it's just the agility thing and promoting SASL2 is the way to go

  110. Zash

    The pains with upgrading to SCRAM-SHA-256 is more implementation issue and that you need the plain text password again

  111. Ge0rG

    Zash: did you just say PLAIN auth? :D

  112. Zash

    no

  113. Zash

    I mean Corporate Enterprise Mandatory Password Change Policy

  114. SamWhited

    Okay, thanks, that's what I needed to get out of this. I'm convinced for now; leaving it as is. Thanks for sanity checking me (and finding me insane)

  115. SamWhited

    I should re-read SASL2. Did an experimental implementation of it when it came out, but I don't recall the details.

  116. jonas’

    I still need convincing that this is a thing concerning XMPP specifically

  117. SamWhited

    Does it provide a way to force reset passwords? That seems like the most important thing to me

  118. SamWhited

    jonas’: it's not concerning XMPP specifically

  119. jonas’

    why is this a XEP then?

  120. jonas’

    an XMPP Extension Proposal document

  121. Zash

    You need some signal to say "hey, password change time", if you receive the password encoded in SASL PLAIN doesn't matter

  122. Zash

    Without letting clients fall victim to MITM

  123. SamWhited

    jonas’: because the XSF is in a position to make recommendations for the public jabber network and it's much better if people can get them in one place instead of all over the place and specific bits of it may be specific and common problems when implementing things for the Jabber network, eg. how to handle PLAIN alongside SCRAM-SHA-1 which are both mandated by RFC 6120)

  124. SamWhited

    that's not true, PLAIN isn't mandated by 6120 IIRC, but it's common to implement in Jabber alongside SCRAM-SHA-1 for compatibility with the widest range of clients, so having a recommendation for how to do that is good.

  125. SamWhited

    Another example is the PBKDF2 iteration count. Right now most people use 4096 which is rather outdated (NIST and OWASP recommend 10000). If you look around on the web you'll find a mix of recommendations for various numbers, but which one applies to the Jabber network? Is it a low security environment or a high security environment? Should I use 4096, 10k, or 100k?

  126. pep.

    Zash, any clues of how to use Coporate Enterprise Mandatory Password Change sasl policy without sending PLAIN? or was PLAIN assumed

  127. SamWhited

    This document clarifies that, even though you're right, technically PBKDF2 iteration count isn't specific to jabber.

  128. pep.

    I know corporate setups can require password policies, but I'd prefer encouraging SCRAM also fwiw, even during account creation/password change (where it's not used atm)

  129. pep.

    Ideally I'd use client certs, but for now we all have to deal with passwords..

  130. SamWhited

    pep. you can't mandate it during password change or you lose the ability to be agile and then when your password hashing mechanism is broken all your users get their passwords stolen. This is *much* worse than the server getting your password once in a blue moon.

  131. pep.

    once and for all you mean

  132. pep.

    Not entirely sure what you mean by not being able to mandate it during password change

  133. SamWhited

    You can't mandate using SCRAM or something during password change, like you were suggesting, I mean.

  134. pep.

    Ah otherwise I can't rehash myself

  135. SamWhited

    Hash and work factor agility is the most important thing, in my mind. Right now we don't have that and it's a major problem.

  136. SamWhited

    However, if SASL2 provides a way to say "you have to reset your password" or "you need to rehash with this iteration count and HMAC hash" that solves the problem nicely in my mind.

  137. pep.

    But via requiring another channel I can clear the hash/password altogether and for a reset via that other channel

  138. SamWhited

    pep.: didn't understand that bit about another channel, sorry?

  139. pep.

    email etc.

  140. Zash

    If SASL2 lets you say "reset your password please" *after* you authed, then it's better than forcing PLAIN auth.

  141. SamWhited

    Zash: right, definitely after auth :)

  142. pep.

    But yeah I would prefer what Zash just said

  143. Zash

    Then you can use SCRAM mutual auth magic to be sure you're giving the new password to someone who knew your previous password

  144. Kev

    *once* knew, I think.

  145. SamWhited

    Anyways, got what I needed. Ping me via PM or email or something if you have more suggestions for the best practices doc. Thanks again!

  146. pep.

    SamWhited, questions on IBR2

  147. SamWhited

    pep. good timing, I was just about to /part. What do you need?

  148. pep.

    You specify a way to do the register procedure via <iq>, does that mean I can register an account after bind? Or is it specifically for components?

  149. SamWhited

    pep. yah, that all needs to be flushed out a bit more. The idea was to make it compatible with components, but sure, if you're an admin and want to register some accounts for somebody it could be used to make that possible after bind

  150. SamWhited

    We'd probably want to add a discovery mechanism for that though so that servers could decide whether to implement it or not. And it should probably be ad-hoc based instead, but I'm not sure if that should all go in this XEP or a separate one.

  151. pep.

    ok

  152. SamWhited

    Bye for real now; thanks again for the discussion on PLAIN v SCRAM!

  153. pep.

    Is there a way to maybe break the fork relation between linkmauve/memberbot and xsf/memberbot?

  154. pep.

    So I get suggested by default to PR against xsf/memberbot

  155. pep.

    And github is sloooooow

  156. pep.

    "We are investigating degradations to GitHub.com."

  157. jonas’

    yeah

  158. Maranda

    degradations lol

  159. pep.

    It's dead Jim

  160. Maranda

    It's some evil M$ plot, I bet 😂

  161. Guus

    https://igniterealtime.org:443/httpfileupload/c463ba66-b75a-4fe0-b500-11202e11be40/dt180322.gif

  162. !XSF_Martin

    Why GIF?

  163. jonas’

    because efficient 8-bit palette encoding?

  164. flow

    pep., you can ask github to change the primary repo

  165. flow

    i've done that in the past

  166. flow

    simply write them a mail

  167. pep.

    you can do that with a simple click in gitlab :/

  168. pep.

    Also I'm no owner of that repo so maybe they will just tell me off

  169. pep.

    MattJ, ^ (?)

  170. jonas’

    I don’t seem to wield power on that repo either.

  171. Ge0rG

    !XSF_Martin [18:51]: > Why GIF? The patent has expired. GIF is free now!

  172. MattJ

    I've sent Github a request

  173. pep.

    Thanks! :)

  174. pep.

    These should be easy changes: https://github.com/xsf/memberbot/pull/2 https://github.com/xsf/memberbot/pull/3

  175. MattJ

    That email came out longer than I planned

  176. Syndace

    Awesome, thanks!&

  177. Syndace

    I'm a little surprised that you don't see a difference between responses and actions, maybe I'm still missing something important. I think the two use-cases of memberbot and and mercurial (:D) bot are already an example of why these two are separate, aren't they? One of them you only want for the last message, the other you want for all (or more) messages. One of them you want with backward compatibility using only plaintext, the other one you want with unique ids so that multiple messages are flexibly possible.

  178. Syndace

    You could merge both and then define that responses that define a body may only be available on the most recent message.

  179. Syndace

    I'd imagine you'd end up with a set of rules that depend on the body to be there or not, essentially splitting the merged element based on that. But that might just be wrong?

  180. MattJ

    I don't think I necessarily agree that actions can't have a body

  181. MattJ

    "!merge 245" seems like a good example

  182. pep.

    "merge !245" :p

  183. Zash

    !merge !245

  184. Zash

    !merge!!245!!!

  185. pep.

    hmm I wasn't even picturing "normal" bot commands using this tbh

  186. pep.

    In general I'd also prefer bots to use ad-hoc I think

  187. Zash

    in muc?

  188. pep.

    dunno, it just rejoins my usual rants about semantics in body :P

  189. pep.

    Even though with a bot you can generally make that more obvious and slightly restricted

  190. MattJ

    When one of the people proposing forms or ad-hoc commands goes and implements either in one of the mobile clients in a nice way, I'll listen

  191. Zash

    Shall I dig up my Buttons implementation?

  192. Zash

    Had a working prototype hacked up in JabberCat back when I wrote the protoxep

  193. Syndace

    > "!merge 245" seems like a good example It is a good example, there is no reason to forbid this. But how to handle this cleanly. Have an "unique" flag on each <response>, if set allow selecting the response even if it's not the most recent message, if not set limit to the most recent message?

  194. Syndace

    Or actually, my argument was that a bot can totally still accept this, just that there is no button for it

  195. Syndace

    The button would say "merge" and send an <action-selected> with the corresponding id, the bot could obviously still accept a manually written "!merge 45"

  196. MattJ

    Sure. But I see no reason to hide the button either

  197. MattJ

    And as noted there is UX weirdness if buttons just disappear

  198. Syndace

    No it wouldn't be hidden, just the button would not generate the "!merge 45" output

  199. MattJ

    Why not?

  200. Syndace

    No hard reason. It probably doesn't have to, because the mercurial bot will send a "45 merged by foo" notification as soon as you click "merge"

  201. Zash

    MattJ, question about room activity indicators: Is it supposed to only work while the client is online?

  202. MattJ

    Yes

  203. MattJ

    Which is why it uses presence

  204. Zash

    Mhm

  205. Syndace

    My idea was that the bot knows best when to print stuff and when not to. Thus the action buttons would not print anything, because the bot can just do so with much finer control.

  206. MattJ

    That's kinda my reasoning for giving it the decision about whether there should be a <body> in the user response

  207. pep.

    MattJ, I'm not really thinking about mobile right now :)

  208. pep.

    definitely not my main use-case

  209. MattJ

    pep.: non-mobile is not this protocol's main use case... console users are used to typing ;)

  210. pep.

    But accepting and having this buttons xep being used does bring "concerns"

  211. pep.

    As dwd said

  212. MattJ

    "concerns"

  213. pep.

    > So I can see that these are useful, but I'm worried they'll end up baking in a data-as-text-body construction which is less than ideal, and tricky to move away from.

  214. Zash

    So much text

  215. MattJ

    Sorry, but that's what we have today

  216. pep.

    Yeah and I don't like that either :/

  217. MattJ

    I know you would like to replace all text messaging with semantic XML

  218. MattJ

    But users don't care, sorry

  219. pep.

    Users don't have to know, as usual

  220. Syndace

    Take the following scenario: a bot for voting. The votes of some members count double, for whatever reason. Now the bot could decide to only print votes of these double-weighted voters, and hide all single-weighted votes to prevent spam. While a little theoretical, that would only possible if the body isn't fixed in the <response>.

  221. MattJ

    Sure, so it sets unique ids, no body, and echoes whatever it wants whenever it wants

  222. pep.

    (fwiw, dave's quote here is a borderline argument in favour of XHTML-IM. I note :p)

  223. Syndace

    The bot would decide what goes into the body. So why not just have the bot do the printing itself?

  224. MattJ

    I think in most cases it will flow nicer if the response comes from the user rather than the bot. But I agree it depends on the use case

  225. MattJ

    Feels borderline security-ish too

  226. MattJ

    Seeing Ralph write "+1" in a meeting is more reliable than seeing a not write "Ralph said +1"

  227. Syndace

    Having the bot specify text that appears to be from the user?

  228. MattJ

    Not == bot, my phone refuses to recognise the word

  229. Syndace

    Oh, I guess both directions can appear borderline security-ish :D

  230. pep.

    I'm sure ralph would be able to correct that itself if it happened

  231. Syndace

    Clicking on "yes" and having "no" appear in the chat because the bot defined it that way is also weird

  232. MattJ

    True, that is definitely a consideration

  233. MattJ

    Agreed, no UI should send a body the user isn't aware of

  234. Syndace

    okay. That's an argument for a) removing labels from (what is now) <response> b) not adding a body to (what is now) <action>

  235. MattJ

    But you have to trust the bot either way

  236. MattJ

    Otherwise it will just echo the "wrong" thing

  237. Syndace

    yes, you'd have to clarify that then followed by kicking the bot from the MUC :P

  238. Zash

    Could recommend showing it in UI like "Merge (sends "merge #123")" or somesuch.

  239. Zash

    or something something descriptions

  240. Syndace

    I'd like to avoid mandating such kinds of UI details, though if you want something like that super hard I won't veto

  241. Syndace

    I think the cleanest thing we can do is: - Have buttons for plaintext responses display exactly what they will send - Have buttons that trigger actions display what the action does

  242. Zash

    Yeah, protocol specifications should stay away from UI design, tho offering suggestions is fine.

  243. MattJ

    There is plenty of precedent for UI requirements in security considerations ("This piece of information MUST be clearly visible to the user")

  244. Zash

    I'm going to default to "that's silly"

  245. MattJ

    Syndace, makes sense I think

  246. MattJ

    But we still need to figure out visibility I think

  247. MattJ

    e.g. now if I wanted to make an in-MUC voting bot, and I wanted to make quick responses for +1/-1, I can't detect what they are in response to

  248. MattJ

    Those kinds of buttons would need to be hidden if the bot sent a new voting item

  249. Syndace

    I imagined that the (action) buttons would be displayed right with the message they belong to

  250. MattJ

    and then people with clients that don't do actions can't vote?

  251. MattJ

    or they have to manually type +1 now, and we aren't able to offer them quick responses on mobile

  252. Syndace

    they could only vote via +1/-1 for the newest vote then, yes

  253. Zash

    Unless! <delay/> tag something something

  254. MattJ

    Let's keep the awkward <delay/> tag out of it :)

  255. Syndace

    oh you're talking about clients that support only the quick response subset of the xep?

  256. Zash eyes `~/src/xeps/origin-timestamps.md`

  257. Syndace

    i.e. not the actions thing

  258. MattJ

    No, I'm working on the assumption that clients would implement the whole thing

  259. MattJ

    But probably not explaining myself well, tired

  260. Syndace

    Okay. Then if actions are used for +1/-1, people with supporting clients could also vote for older items. Which the bot would and should probably prevent. People with clients that don't support would have to manually type +1/-1 and have it count only to the most recent vote item

  261. MattJ

    Yeah, you're right

  262. Zash

    That's usually not how voting works tho

  263. Syndace

    There is a third option which is not covered currently: a quick response that is not limited to the most recent messrage, but maybe until it is explicitly ended. MattJ> !vote votebot> vote started. *+1 and -1 quick responses appear for everybody* someone> +1 anotherone> -1 MattJ> !done votebot> vote done. *quick responses disappear for everybody*

  264. MattJ

    I worry about adding work for clients

  265. MattJ

    But indeed, that is a possible solution

  266. Syndace

    yeah, that would probably be complicated.

  267. Zash

    `<in-reply to="xmpp:id"/>`

  268. MattJ

    (removing the merge button after merging a PR would be great)

  269. MattJ

    Going to sleep on this - good night!

  270. Syndace

    I should too, good night :)