XSF Discussion - 2017-03-06


  1. jonasw

    Ge0rG: I think it is pretty clear how to send a message to a MUC.

  2. Ge0rG

    jonasw: but there is no way to know that it arrived :P

  3. jonasw

    indeed :-)

  4. jonasw

    uh

  5. jonasw

    we should try to smuggle a <feature var='muc_keeps_ids' /> in your PR

  6. Ge0rG

    jonasw: I tried and failed, some two years ago. I think clients that care enough just need to embed a [xep 359] tag

  7. jonasw

    ah clever

  8. Ge0rG

    jonasw: I consider it a crude hack.

  9. jonasw

    depends on the point of view regarding the id uniqueness per stream

  10. Ge0rG

    I know that XMPP is old, but it's had sufficient time and opportunity to adapt and to make reliable message routing a first class citizen

  11. jonasw

    will we get that with MIX?

  12. jonasw

    (.oO(make all <message/>s <iq/>s!)

  13. jonasw

    )

  14. Ge0rG

    and instead we've got acks, stream management, carbons, mix, stable-message-ids, which all solve partially overlapping partial problems.

  15. jonasw

    not sure that anything of acks, SM and Carbons is really overlapping.

  16. Ge0rG

    I really don't want to get started about this today. I haven't had my coffeine yet, and there is an important meeting in one hour :>

  17. jonasw

    :D

  18. Ge0rG

    jonasw: SM and acks both implement message reliability mechanisms, two faces of the same medal.

  19. jonasw

    but on a different scope

  20. Ge0rG

    jonasw: it's absolutely the same logic, just different endpoints.

  21. jonasw

    yes

  22. Ge0rG

    except one is a message attribute and the other is a nonza.

  23. jonasw

    that’s what I mean by differetn scope

  24. jonasw

    *message child element I hope

  25. Ge0rG

    right.

  26. Ge0rG

    and then we have the problem that carbons don't carbonate 0184 acks because those are "normal" messages.

  27. jonasw

    carbons is a mess

  28. Ge0rG

    I'm asking for multiple years now to replace carbons and "classic" bind with a MAM subscription mechanism.

  29. Ge0rG

    you authenticate, and instead of doing all the crufty "bind session, enable carbons, query MAM, send presence" just do a nice and simple bind2 with MAM subscription.

  30. Ge0rG

    depending on the order of the above, you'll get crazy side effecs.

  31. jonasw

    yeah, I got that from the bind2 xep

  32. Ge0rG

    but bind2 still doesn't give us MAM subscription

  33. jonasw

    I was also wondering about a different thing. Assuming I have a MIX in my roster and a client freshly connects to my account. Then right after the connection is established (before the client got a chance to send any disco#info requests), someone writes a message in the MIX and my client thus gets a message from somemix+someuser@mixservice. How is it supposed to know that this is a mix and show the message correctly?

  34. jonasw

    is MAM subscription a thing?

  35. Ge0rG

    so we have two different mechanisms for offline and online sync now, with different message retention properties.

  36. Ge0rG

    jonasw: I suppose your MIX proxy will figure out from the client's caps that it's not MIX enabled

  37. jonasw

    well, no, the client *can* do MIX

  38. jonasw

    but it hasn’t seen the account yet

  39. Ge0rG

    jonasw: otherwise, you're f***ed.

  40. Ge0rG

    jonasw: this is exactly why I'm complaining about MIX-in-roster

  41. jonasw

    what does this have to do with MIX-in-roster?

  42. Ge0rG

    jonasw: implicit join on connect.

  43. jonasw

    I think that’s a feature

  44. Ge0rG

    jonasw: until you get a message from a MIX.

  45. jonasw

    yes well, I need to know that it’s a MIX

  46. Ge0rG

    yes you do

  47. Ge0rG

    jonasw: you could spawn a thread to process that message, and have the thread query the domain / plus-less JID / something about what it is.

  48. jonasw

    thanks, but that’s insane

  49. Ge0rG

    jonasw: you could also just do a blocking query :P

  50. jonasw

    that’s not better

  51. Ge0rG

    jonasw: maybe your client can see that you are in somemix@mixservice from your annotated roster, and thus determine that somemix+someuser@mixservice must be a participant of that mix?

  52. jonasw

    that could worl

  53. jonasw

    *work

  54. jonasw

    if the roster is actually going to be annotated, that could indeed work.

  55. jonasw

    won’t work for mixes which are not in the roster thoguh

  56. Ge0rG

    In the context of auto-generated UUID-JIDs for private MUCs/MIXes, there is an interesting question of how to prevent impersonation attacks.

  57. jonasw

    Ge0rG: reject MIXes/MUCs with anonymous settings for that purpose?

  58. jonasw

    and then look up the JIDs to make sure they match

  59. jonasw

    uhm, I may not be so sure about your usecase anymore

  60. Ge0rG

    jonasw: if the MIX/MUC is on a different server than yours or your inviting contact's, the MIX/MUC can misbehave and feed you "trusted" JIDs

  61. jonasw

    if you assume that the service is evil, end-to-end is probably the only way out

  62. Ge0rG

    jonasw: I assume that my own server is not evil, but an evil third-party server might exist.

  63. jonasw

    still applies

  64. Ge0rG

    jonasw: I think there is room for a security model somewhere between "trust everybody" and "trust nobody, run e2ee everywhere"

  65. Ge0rG

    jonasw: something like "trust my server to properly handle MUCs and contacts, and not to lie to me about users' JIDs"

  66. Ge0rG

    jonasw: otherwise we are deep into sign-MUC-invitations-and-participant-lists-with-OMEMO land

  67. jonasw

    yes, but that’s not a way to prevent impersonation attacks; that’s a way to say "they don’t matter because those who can execute them won’t do that"

  68. Ge0rG

    jonasw: good point. Then we really need to sign every presence and message.

  69. jonasw

    indeed

  70. jonasw

    or use peer-to-peer MUCs :-)

  71. jonasw

    (although that still needs E2E)

  72. Ge0rG

    jonasw: the only secure way to make trusted identities is to route-to-publickeys, like Tor and similar.

  73. jonasw

    yeah, I do not see that happen with XMPP

  74. Tobias

    you can perfectly use XMPP with onion domains

  75. Ge0rG

    Tobias: that's completely orthogonal.

  76. Ge0rG

    Tobias: unless you want each user to run their own .onion xmpp server.

  77. Tobias

    right

  78. jonasw

    why not! that also gives us client-chosen identifiers in JIDs! :>

  79. Ge0rG

    jonasw: was it jonasw@6HbHXvQ00HcXJMWYlC5lpeU5.onion or jonasw@hC19YDLyWPC6jAFVQDlH78Lf.onion again?

  80. jonasw

    distributed name services!

  81. jonasw

    also, you would know, because your client lets you choose by public key (including meta information), not by .onion address

  82. Ge0rG

    Zooko called, and he wants his triangle back.

  83. Ge0rG

    jonasw: so I'd choose by "6HbHXvQ00HcXJMWYlC5lpeU5" vs "hC19YDLyWPC6jAFVQDlH78Lf"?

  84. jonasw

    no, the key with title "Jonas Wielicki" you signed when we met at CLT 2017 ;-)

  85. Ge0rG

    meta information can be faked.

  86. Ge0rG

    jonasw: but we never met at CLT 2017.

  87. jonasw

    now that’s tricky

  88. jonasw

    ;-)

  89. Tobias

    if we get the lookup/bootstrapping problem solved it doesn't matter how cryptic the JID looks :)

  90. Ge0rG

    exchanging xmpp addresses is hard enough already without routing-by-publickey

  91. Ge0rG

    Tobias: are we putting a pubkey-routed overlay network on top of xmpp now?

  92. Tobias

    I'm certainly not

  93. Tobias

    put you probably could do serverless XMPP via DHT discovered endpoints :)

  94. Tobias

    everything is supposed to be serverless nowadays anyways ;)

  95. Ge0rG

    Tobias: right. or serverless xmpp on .onion domains, to reuse existing tech

  96. jonasw

    i wanted to implement serverless for fun anyways

  97. Tobias

    still have the bootstrapping/contact lookup problem though

  98. Ge0rG

    Tobias: QR codes printed with your blood onto calfskin.

  99. Ge0rG

    the blood provides a strong binding to your identity, via DNA

  100. Ge0rG

    maybe there is even some way to cryptographically hash your DNA info to make a truly-personal keypair.

  101. Tobias

    Ge0rG, people get cloned, then what?

  102. Ge0rG

    Tobias: only a large government service is able to clone people. This attack vector can be safely ignored for normal people.

  103. Tobias

    they cloned dolly in the 90s, didn't they..must be dead cheap by now

  104. Ge0rG

    Tobias: I hope you didn't intend to make that a tasteless pun. :D

  105. Tobias

    at first not, but now that i reread that message :)

  106. jonasw

    :D

  107. Tobias

    nyco, https://mongoose-os.com/ is not related to mongoose XMPP server, is it?

  108. nyco

    Nope ;-)