XSF Discussion - 2018-12-31

  1. vanitasvitae

    I think I'm on a tagged version

  2. vanitasvitae

    Have to upgrade soon anyways ;D

  3. lovetox

    hm one moment

  4. lovetox

    what could also be is that the xml lib of dino prints this wrong

  5. lovetox

    but i guess less likely as it would have to happen with all stanzas then

  6. lovetox

    really weird bug

  7. Neustradamus

    It is possible to add new SCRAM in next XMPP Compliance Suites?

  8. Wiktor

    > I thought "xmlns='urn:xmpp:bob'" would be illegal. Xml namespaces are URIs but practically any XML lib treats them as strings anyway (no validation). In your case the namespace is URN, colons are frequent in URNs :) (check out Wikipedia)

  9. jonas’


  10. jonas’

    vanitasvitae, that bug sounds familiar

  11. jonas’

    daniel, see above, I think you had the same thing the other day?

  12. jonas’

    vanitasvitae, what you’re seeing there sounds very much like what daniel had in https://github.com/siacs/Conversations/issues/3315

  13. jonas’

    there seems to be some ejabberd bug there

  14. vanitasvitae

    jonas’: thanks for the link

  15. jonas’

    Neustradamus, new SCRAM? what are you talking about?

  16. lovetox


  17. jonas’

    are the weakened security properties of SHA-1 relevant for SCRAM?

  18. Zash


  19. jonas’

    then I don’t think it’s worth the trouble

  20. Zash

    Not that I know of at least

  21. Zash

    IIRC even HMAC-SHA1 is fine for things that HMACs are appropriate for

  22. Zash

    So yeah, combined with that you can't convert the hashes, it's not really worth it

  23. lovetox

    why was it then specified?

  24. jonas’

    for new deployments probably

  25. Zash


  26. lovetox

    but why if it doesnt increase security

  27. jonas’

    but in existing deployments, migrating the SCRAM version is a PITA -- you need a password change to achieve that

  28. jonas’

    safe is better than sorry?

  29. lovetox

    hm not really convincing ..

  30. Zash

    Why use modern crypto?

  31. lovetox

    This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- SHA-256-PLUS. SHA-256 has stronger security properties than SHA-1, and it is expected that SCRAM mechanisms based on it will have greater predicted longevity than the SCRAM mechanisms based on SHA-1.

  32. lovetox

    seems to be it does play indeed a role and is relevant

  33. Zash

    > SHA-256 has stronger security properties than SHA-1, This is true.

  34. Zash

    But whether that matters for how they are used in SCRAM is something different

  35. lovetox

    does not make much sense to specify a hash with great seurity properties, if you dont need these properties at all

  36. pep.

    Just like ipv6 was specified in the past, and still not used in the present, maybe someday in the future..

  37. Zash

    The real question is why not just wait for SCRAM-SHA-3

  38. jonas’

    See [RFC4270] and [RFC6194] for reasons to move from SHA-1 to a strong security mechanism like SHA-256.

  39. jonas’


  40. Zash

    What do they say?

  41. jonas’

    TL;DR (yet)

  42. Zash

    Attacks on Cryptographic Hashes in Internet Protocols Ctrl-F "HMAC" - 0 matches

  43. jonas’

    3.3. HMAC-SHA-1 As of today, there is no indication that attacks on SHA-1 can be extended to HMAC-SHA-1.

  44. Zash

    lovetox: it's an improvement, but relatively small improvement.

  45. lovetox

    yeah probably :)

  46. jonas’

    I’m composing a question on crypto.stackexchange about this

  47. Zash

    Remember that the state of the art before SCRAM was DIGEST-MD5 and storing plain text passwords.

  48. Zash

    DIGEST-MD5 -> SCRAM is a huge improvement all around

  49. Zash

    SCRAM-SHA-1 -> SCRAM-SHA-256 is a small improvement that would cost a lot for existing deployments

  50. Zash

    Converting plain text passwords to hashed form is easy. Converting hashed form to a different hashed form is Hard

  51. lovetox

    im not arguing for or against this new standard, it just was a contradiction to me that the ietf goes through the motion of making a new standard with a more expensive hash method, if it has no effect at all on security

  52. lovetox

    maybe it was "better save than sorry" but bringing such a standard to live seems to me a bit of work that nobody would do just because he feels like 256 is a prettier number

  53. Zash

    not no effect, it's better. but not enough better to outweight the cost of switching

  54. lovetox

    yeah you are probably right on that

  55. lovetox

    it is though really easy to implement if you already have a SHA1 impl

  56. Zash


  57. Zash

    In theory it's just replacing the hash function

  58. Zash

    So if you have code that makes that easy then it's easy

  59. jonas’

    there we go https://crypto.stackexchange.com/q/66195/16902

  60. lovetox

    great writeup :)

  61. Zash

    There's one spot in SCRAM where it uses bare SHA-1 tho, for converting the ClientKey into StoredKey

  62. Zash

    StoredKey := H(ClientKey)

  63. jonas’

    oh, I missed that

  64. jonas’

    but storedkey is never transferred and only used as key in the hmac

  65. Zash

    But ClientKey is HMAC output and not combined with anything

  66. rion

    Does any XEP describe disco#info get requests with non-empty query element? Just found this in iris code w/o any reference to specs.

  67. Zash

    rion: I think there's something like disco-subscriptions somewhere, but I'm not sure if there's a XEP

  68. rion

    I see xep-0230 but there is disco#items

  69. rion

    Ok, thanks Zash. I'll put it under #if 0 for now

  70. oli

    didn't we had the sha-256 discussion before? or was it at ejabberd?

  71. Ge0rG

    rion: IIRC it is also used in MIX to distinguish between MUC protocol and MIX protocol, but maybe it was disco#items as well

  72. jonas’

    Ge0rG, no

  73. jonas’

    MIX uses the node for that

  74. jonas’


  75. jonas’

    you confuse that with the roster query

  76. jonas’

    so I’ve been thinking about MUC self ping. thinking about it, using a silent, non-archived <message/> might actually be the most traffic-efficient way to do it.

  77. Ge0rG

    jonas’: wasn't there disco#items on the MIX room JID to get a list of all nodes?

  78. Ge0rG

    jonas’: a message to whom?

  79. jonas’

    Ge0rG, through the MUC

  80. jonas’

    so to everyone, essentially

  81. Ge0rG

    jonas’: to the MUC?

  82. Ge0rG

    How's that more traffic efficient?

  83. jonas’

    it is a ping for everyone. only one needs to send it, everyone else also learns that they themselves are still connected.

  84. jonas’

    it is a ping for everyone. only one client needs to send it, everyone else also learns that they themselves are still connected.

  85. jonas’

    so it saves sending the ping for everyone but one client.

  86. jonas’

    Ge0rG, MIX uses @node='mix' to qualify that; no need for child elements on the <{…disco#items}query/>

  87. jonas’

    back to muc self-ping: if everyone implements it with "after N+random(-1, 1) minutes of no message received through the MUC, send a ping <message/>; if after N+M (M>2) minutes no message was received, conclude that we’re disconnected", the one with the lowest random() output will be the one who sends the pings, and everyone else silently benefits from it.

  88. jonas’

    does that make sense?

  89. lovetox

    sounds weird, but somehow i like it

  90. lovetox

    wonder if this has any downsides

  91. Ge0rG

    jonas’: provided that we can normalize N. Also there might be minor inefficiency when multiple clients roll the same number. But I fear there will be clients making a short cut and not checking for the last incoming message, just sending anyway

  92. jonas’

    potential downsides: if the MUC eats the <message/> (because it’s bodyless or whatever), it breaks. if the MUC archives the message, it pollutes the archive massively.

  93. jonas’

    Ge0rG, slap those clients then.

  94. lovetox

    there are store hints for exactly that usecase

  95. lovetox

    and bodyless is no problem in any muc

  96. jonas’

    lovetox, it may be with biboumi

  97. jonas’

    but I think even biboumi simply reflects those on the XMPP side and drops them on the IRC side

  98. Ge0rG

    jonas’: but how is it better than the 0410 proposal?

  99. jonas’

    Ge0rG, 1. it requires no server-side implementation; 2. in my specific implementation, it is easier to keep multiple <messages/> in flight and have a catch-all handler for the replies than with IQs (because IQs are request-response, and each in-flight IQ needs an entry in the response handler table -> memory use); 3. what happens when you send a message to a MUC you’re not joined to is more well-defined than IQ, 4. no race conditions with nickname changes or whatever

  100. lovetox

    the self ping has on its positive side that its easier to implement

  101. Ge0rG

    Also it might make sense to have different N for mobile vs desktop clients, and your suggestion ends up with `min(N) ` over all participants

  102. jonas’

    (I don’t find it easier to implement, see (2) above)

  103. Ge0rG

    jonas’: some MUCs allow messages from non participants. What now?

  104. jonas’

    Ge0rG, that’s a true point. For what it’s worth, a MUC implementation could still not forward the message to all participants but only reflect it to the sending client, if we find that it’s a battery hog.

  105. jonas’

    Ge0rG, eh, why :D

  106. jonas’

    I think with that, my proposal falls down the drain

  107. jonas’

    good that we talked about it though

  108. Ge0rG

    jonas’: don't know why. Also some bridge implementations (looking at you, biboumi) will accept a message from a non joined resource of a joined user

  109. lovetox

    it is jonas in my opinion, one is just send an iq and wait for response, the other is, check messages for something then start a timer that i have to reset on the next message, and deal with over multiple scenarios like disconnect etc

  110. jonas’

    lovetox, how long do you wait for a response for the IQ?

  111. lovetox

    lots of space to have bugs

  112. jonas’

    no, you don’t need ot check messages for something

  113. jonas’

    *every* message you receive lets you know you’re joined

  114. jonas’

    you need that timer anyways if you want to implement self-ping efficiently.

  115. jonas’

    you don’t need to send a ping when you just received a message from the MUC.

  116. lovetox

    hm yeah

  117. lovetox

    seems similar

  118. jonas’

    (hint: the same thing goes for your main xml stream ;-))

  119. jonas’

    problem with the IQ ping is the timeout

  120. jonas’

    using a long timeout has the downside that if the MUC was temporarily blackholed, you have to wait very long until you can resync

  121. jonas’

    using a short timeout has the downside that you won’t resync automatically in a high-latency situation.

  122. jonas’

    using multiple interleaved pings with long timeout has the memory cost issue

  123. Ge0rG

    jonas’: on timeout you should just mark the MUC as not responding, and schedule a new ping

  124. jonas’

    Ge0rG, that’s obvious

  125. Ge0rG

    No need to have multiple interleaving pings

  126. jonas’

    which timeout should I use for the ping then?

  127. lovetox

    i dont know what you are talking about memory, a timeout, compared to a full fletched gui client Oo

  128. jonas’

    lovetox, aioxmpp might very well be used for a bot which runs ~forever and if it loses connectivity which isn’t restored, I don’t want it to turn into a memory hog

  129. jonas’

    I don’t like ever-growing tables.

  130. jonas’

    (and by "loses connectivity" I mean "a MUC in which it is joined becomes blackholed")

  131. Ge0rG

    jonas’: have a ping timeout of 60s and a ping interval of 10m after the last activity

  132. jonas’

    Ge0rG, so if my link has a latency higher than 60s, I don’t ever resync to the MUC; it is "not responding" forever.

  133. Ge0rG

    jonas’: correct.

  134. jonas’


  135. Ge0rG

    Make it configurable for the military satellite use case

  136. jonas’

    me not likey

  137. jonas’

    lovetox, by the way, XEP-0410 even tells you to not self-ping unless the MUC is silent: > After an adequate amount of silence from a given MUC (e.g. 15 minutes), or from all MUCs from a given service domain, a client should initiate a self-ping.

  138. lovetox

    i just dont like timers, i pass a callback to some timer api, and later it comes back and bites me, either because the object for the callback is not there anymore, or because i forgot to cancel the timer if any of X events happen

  139. Ge0rG


  140. jonas’

    which is why I wrapped this specific logic (which I already needed for the main xml stream anyways) in a class which takes care of handling the timer

  141. jonas’

    I just should "nevermind, I got data!" at that class from time to time, and when I don’t do that, it’ll tell me "hey, no data for X time, wanna do something about that?"

  142. jonas’

    I just shout "nevermind, I got data!" at that class from time to time, and when I don’t do that, it’ll tell me "hey, no data for X time, wanna do something about that?"

  143. Zash

    Prosody has something like that too.

  144. jonas’

    so I can be reasonably confident that when that event triggers, something is wrong

  145. lovetox

    you just described a callback...

  146. lovetox

    i think we all know how this works

  147. jonas’

    lovetox, typical callback APIs are a bit more convoluted than that though

  148. jonas’

    (also, this has in fact two timers, a soft and a hard timeout)

  149. jonas’

    you normally need to store some handle and exchange that whenever you re-set the timer

  150. jonas’

    but that’s implementation details

  151. jonas’

    I’m just saying one can make this rather painless

  152. lovetox

    its painless if you have not many events that need the timer to be deleted, like an xml stream, what is there, essentially disconnect() thats the only event where you stop the timer

  153. jonas’

    same goes for a MUC room. "leave" is the only thing where you stop the timer.

  154. lovetox

    think about chatstates, i have a inactive timer, it has to be reset whener the mouse moves over the window, if i switch the window, if i close the window, if i disconnect, etc this goes on and on

  155. lovetox

    but yeah, i see it depends on what you do with the timer

  156. lovetox


  157. Neustradamus

    jonas’: https://tools.ietf.org/html/rfc7677 + https://tools.ietf.org/html/draft-ietf-mile-xmpp-grid-08

  158. vanitasvitae

    Happy new year!

  159. pep.

    Happy public domain day

  160. jonas’

    happy new year’s from CET https://sotecware.net/images/dont-puush-me/WVeQE5W9eDNjekWpVcI5J0z5i6kPBYXRJTHfxKQ_DF0.png

  161. jonas’

    happy new year from CET https://sotecware.net/images/dont-puush-me/WVeQE5W9eDNjekWpVcI5J0z5i6kPBYXRJTHfxKQ_DF0.png

  162. waqas

    pep.: I didn't realize that was a thing. Looks like "Yes! We Have No Bananas" is now in the public domain, https://www.youtube.com/watch?v=PDd8shcLvHI

  163. waqas

    There seems to be a list here: https://lifehacker.com/these-1923-copyrighted-works-enter-the-public-domain-in-1825241296

  164. Seve

    Happy new year! :)