XSF Discussion - 2016-05-18

  1. moparisthebest

    if only we could make XMPP use this new cipher "We created a cipher that is 6,000,000 times stronger than current data security, as proven by algorithmic mathematics." https://www.kickstarter.com/projects/datagatekeeper/datagatekeeper-the-first-impenetrable-anti-hacking

  2. moparisthebest

    yikes, can anyone read that without cringing? :P

  3. Zash

    Not even gonna try

  4. Ge0rG

    is it my copy&paste-fu, or is that link a 404?

  5. Ge0rG

    oh, it's the former.

  6. moparisthebest

    you know you want to read it Zash haha

  7. Ge0rG

    moparisthebest: I wonder if the icon is supposed to represent a trojan horse or my little pony.

  8. edhelas

    Ge0rG, both

  9. Ge0rG

    This is the Total Data Protection! /:=O

  10. dwd

    That one is so hyperbolic.

  11. edhelas

    XMPP Compliance Suites 2016 <3

  12. edhelas

    would be really nice to have the validation system to promote the apps that are compatibles

  13. SamWhited

    Just updated to add a mobile compliance suite as well; suggestions for what should go in it are welcome: https://github.com/xsf/xeps/pull/185

  14. SamWhited

    Probably going to add stream compression, EXI, and push notifications at least at various levels.

  15. edhelas

    For Movim it's a bit weird actually, because I'm not really a web client, but not a "IM" client as well

  16. SamWhited

    Is movim that social networking thing?

  17. Zash

    SamWhited: Don't we consider stream compression horribly insecure nowdays?

  18. edhelas

    SamWhited, yup

  19. edhelas

    basically it's a "webmail" but for XMPP

  20. SamWhited

    Zash: probably, I don't buy it though as long as you do a full flush on stanza boundaries

  21. SamWhited

    I don't buy that it's a problem, that is.

  22. SamWhited

    I guess that will probably come up when the discussion about moving it forward happens though, so good to start thinking about.

  23. Zash

    Well it's gone from the next Prosody fwiw

  24. Holger

    SamWhited: I don't know whether or not it's a problem, but it doesn't sound essential for interop/UX to me.

  25. SamWhited

    Holger: It helps a lot on mobile when you have a X000 person roster.

  26. Holger

    You have too many friends.

  27. Zash

    SamWhited: Even with various CSI optimizations?

  28. Link Mauve

    edhelas, Movim definitely is both a web client and an IM client.

  29. SamWhited

    Coworkers, but yah, we (Atlassian) aren't even one of our (HipChat's) bigger groups.

  30. SamWhited

    Zash: Not sure about that; wish I could convince them to let me deploy my implementation.

  31. edhelas

    Link Mauve, yeah but all the XMPP part is done server side, with a stable and good Internet connection

  32. SamWhited

    edhelas: Does Movim not make an XMPP connection to the server?

  33. edhelas

    Holger, I have ~300 contacts in my roster, some clients really have issues to process it :p

  34. edhelas

    SamWhited, it does but server side, basically you have

  35. edhelas

    User Browser <- HTML + Websocket -> Web Server <- Pure XMPP TCP/TLS -> XMPP Server

  36. Holger

    edhelas: I guess compression won't help those clients though :-)

  37. SamWhited

    edhelas: Yah, if it makes an XMPP connection to the server, I'd say that means it fits in the web compliance category (in the sense that you'll need either BOSH or websockets to connect, and you'll have to implement the XMPP subprotocol of one or the other presumably)

  38. Link Mauve

    315 here, and my main client is really slow at processing their presence. ^^'

  39. SamWhited

    Unless your HTML+Websocket connection isn't XMPP? I'm still confused.

  40. Holger

    Everyone has more friends than me.

  41. edhelas

    no it's pure "web" websocket, there is no XMPP at all browser side

  42. edhelas

    as I said, Movim is a "webmail" for XMPP

  43. SamWhited

    Oh yah, wouldn't apply then I guess

  44. dwd

    FWIW, compression is fine and perfectly safe in some cases; but they're oddball ones.

  45. edhelas

    ok :p

  46. edhelas

    Link Mauve, roster + presence processing need to be really well doneif you have a huge roster. It took me some time to have nice performance on Movim, now it process the ~500 stanza of the login in less than 1sec. All in pure PHP :)

  47. edhelas

    the roster is actually read in one time and saved in one request in the DB

  48. SamWhited

    As it should be. If you ever find yourself writing "for whatever { dbcall }" you're probably doing it wrong.

  49. SamWhited

    Build the query, then execute, or you're going to have scaling problems later :)

  50. Link Mauve

    edhelas, I expect your parsing to be way less heavy than slixmpp’s. :)

  51. Link Mauve

    Also, Python is slow.

  52. mathieui


  53. Flow

    I still consider stream compression essential for mobile connections

  54. Flow

    Also I've been working on Smack droping the compression dict state, not only stanza boundary, but on channel change. Where "channel change" means that the recipient bare jid has changed. I believe that this is the best trade-off between security and efficiency

  55. Flow

    Happy to be proven otherwhise and told if this still would be a security issue

  56. SamWhited

    What Flow said ⤴

  57. Flow

    s/not only stanza boundary/not on stanza boundaries/

  58. Flow

    the idea is that you can keep the compression dict state as long as you are sending stanzas to the same entity

  59. Link Mauve

    I’d be interested in having that in Prosody.

  60. Link Mauve

    Especially for s2s, since broadcasting a stanza to many people is very slow on ADSL.

  61. Link Mauve

    And very often you send many stanzas to the same server in a row.

  62. Link Mauve

    Even better, many similar stanzas.

  63. xnyhps

    Compressing single stanzas could allow attackers to discover your real JID to others in semi-anonymous rooms if they can observe the encrypted stanza size.

  64. xnyhps

    s/to others/

  65. xnyhps

    But that's very little payoff for how much access you need.

  66. Flow

    xnyhps: So no big worries with having compression this way from your side?

  67. xnyhps

    You can't easily detect if the server is doing the same, so I still think it's a bad idea.

  68. Flow

    well we coud register a new compression algo like 'zlib-secure'

  69. xnyhps

    I still think you can win a lot more (and actually reduce processing time and information leakage) by making sure stanzas that are sent simultaneously get into the same TLS record.

  70. xnyhps

    With any relatively modern ciphersuite there's at least 41 bytes of overhead per record, the maximum would be ~85 bytes with AES-CBC + SHA384.

  71. SamWhited

    Agree about sticking stanzas in the same TLS record, but I very much doubt you can convince most clients (or servers, for that matter) to try and optimize at that level. Would love to be proven wrong though (hint, hint, client/server developers)

  72. SamWhited

    I'm not sure a zlib-secure algo is needed; just require it in the spec in general and if you implement that version of the spec assume it's being done.

  73. SamWhited

    (if it's not being done, that's a bug but it could equally not actually be happening if they advertised zlib-secure or something)

  74. Tobias

    stpeter, what are the plans for https://github.com/stpeter/xmppdotnet/ ? expanding the team that processes those PRs?