XSF Discussion - 2020-01-07

  1. moparisthebest

    dwd: good article

  2. moparisthebest

    And on that topic, it's about time, does anyone know if anyone has started XMPP over QUIC work yet?

  3. moparisthebest

    It handles switching networks itself, so in theory we wouldn't even need stream management anymore

  4. waqas

    dwd: Is the image under "High Latency" intended to be a gif of a spinning circle?

  5. Arc

    why QUIC instead of SCTP?

  6. Zash

    Arc: New hotness?

  7. dwd

    Waqas, must be slow loading.

  8. dwd

    Arc, QUIC has lower start-up cost, I think, plus it's likely to be around in implementations because of Google pushing it.

  9. flow

    dwd, the xep368 link is broken

  10. flow

    moparisthebest, I'd expect that XMPP over QUIC is not that hard to specifiy, it is probalby even esier than XMPP over TCP+TLS, because QUIC does most of the work for you.

  11. Zash

    dwd, "latencies still have a visible human effect even when they drop below 30ms" - isn't that the other way around?

  12. Zash

    dwd, and browsers supposedly don't do pipelining

  13. dwd

    No, latencies still have an effect that low. Usually because of cumulative interaction, like sequential rtts, but in highly interactive stuff, I think people can still tell there's a lag just on a single rtt.

  14. ralphm

    Arc: primarily because SCTP has been tried before, and stranded on the fact that there is major inertia in middleboxes. They won't support new transport layer supports, and I think that this is the primary reason for Google to start work on QUIC.

  15. flow

    what ralphm said, and just when I asked myself about the differences and similarities between QUIC and SCTP, I found https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00

  16. ralphm

    Yeah, that's an excellent, but bit dated, document.

  17. ralphm

    I have been talking on and off with people about the prospects of XMPP-over-QUIC. Besides having TLS 1.3 built in, and the advantages of fewer round-trips upon reconnection (we probably still need to do work ourselves here, too), I also like the part where you have an identifier for a connection that survives roaming between different networks.

  18. Zash

    The "resource" ?

  19. ralphm

    E.g. when in an office on a higher floor going out for lunch, you'll be going WiFi - Cellular (elevator) - Wifi (lower floor) - Cellular (elevator) - WiFi (lobby) - Cellular (outside).

  20. ralphm

    Zash: the Connection ID: https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-5

  21. dwd

    That scenario is what we see, but on a constant basis as doctors and nurses walk between wards.

  22. Zash

    Moar access points!

  23. flow

    ralphm, Isn't quick designed to survive roaming between different networks?

  24. flow

    ahh you "like the part", I read "like to have"…

  25. flow

    slightly related: As I am working on Smack's lower layers, is there any reason I shouldn't prepare Smack to perform SM resumption over different transports besides TCP?

  26. Guus

    PSA: January 14, 2020 is the deadline for organisations to submit to GSoC. Now that I see some of the usual suspects here, I thought I'd bring that up. flow if we'd choose to apply, would you consider running as org admin again?

  27. flow

    Even though xep198 was probably written with SM resumption only being performed over TCP transports in mind, is there any reason we shouldn't allow SM resumption over different transports?

  28. Guus

    (14 January is in one week from now)

  29. flow

    Guus, as I am just back from vacation I was about to write a mail regarding that

  30. Guus


  31. Guus

    just wanted to stir things. I'll await your email 🙂

  32. flow

    Guus, btw, 14th is not the deadline if I am not mistaken

  33. Guus

    flow you're right

  34. Guus

    that's when registration opens.

  35. Guus

    sorry for that.

  36. Guus

    > All organizations wishing to be a part of GSoC 2020 must complete their application by February 5, 2020 20:00

  37. Guus

    Sorry for butting in the conversation then

  38. flow

    na, no worries

  39. ralphm

    dwd: maybe we should make some time around the summit to work on this?

  40. dwd

    Flow, sm is deployed over websockets by Stanza, Prosody, Openfire, and probably others.

  41. flow

    dwd, so I could resume a session previously connected via TCP over webscokets on Openfire and Prosody?

  42. Ge0rG

    Speaking of SM over websockets, we still miss a way to sm-resume an anonymous session

  43. Zash

    Did ISR allow that?

  44. dwd

    Flow, ... Maybe?

  45. dwd

    Zash, yes, isr would allow that.

  46. dwd

    I think.

  47. Zash

    flow, yes, except for the part where Prosody doesn't officially support 198 out of the box

  48. flow

    So SM with TCP and Websockets ✓ what about SM resumption over BOSH and QUIC?

  49. flow

    I can see that we may not want to put in effort to think about SM over BOSH, as it would potentially duplicate a lot of what BOSH already does, or maybe there is a chance to unify it? But how relevant is BOSH given that we have Websockets now?

  50. flow

    Compared to that, SM over QUIC appears straight forward

  51. dwd

    I think lots of networks will block QUIC, so SM is still useful.

  52. flow

    Probably even if QUIC is available nearly everhwere, SM resumption across transports is still nice to have

  53. Ge0rG

    I agree with that, and resuming 0198 from a gone TCP connection on a BOSH, because you moved into nazi firewall land, seems sensible

  54. ralphm

    dwd: why would they block QUIC?

  55. dwd

    ralphm, Some of the hospitals we work in block everything and whitelist a handful of IP addresses and ports.

  56. dwd

    ralphm, QUIC operates over UDP, right? So I'd imagine there's little hope it'll just work in any kind of "nazi firewall land".

  57. ralphm

    Also note that there's been an effort to allow QUIC to multiplex with STUN and TURN.

  58. ralphm

    So indeed, if you are in a network that also blocks WebRTC, then you'd be out of luck.

  59. ralphm

    dwd: would you count medical institutions in such lands?

  60. dwd

    Some of them certainly are. There's a lot of well-placed concern about infosec in the NHS, especially after the malware attacks a couple of years back.

  61. ralphm


  62. larma

    dwd, nice blog post. Just to play devil's advocate here, I think your "even on mobile" paragraph is not fair. Optimizing for mobile is not only about bandwidth and latency, it also needs to consider energy consumption (which seems to be something where EXI may have some significant advantage over plaintext XML), constantly switching networks (change in ip addreseses / tcp connections breaking up) and data consumption (due to limited plans). Also throttled mobile networks (after you exceeded your "flatrate"'s high speed data) can go as low as 32 kbit/s (shared with all apps on the phone)

  63. pep.

    dwd, "the malware attack", you mean the ransomware?

  64. jonas’

    https://sha-mbles.github.io/ via pep.

  65. ralphm

    I'm not sure if data consumption is affected by using using EXI, though. I believe mobile networks charge based on certain minimum packet sizes.

  66. ralphm

    And dwd has discussed energy usage in his XEP a long time ago already.

  67. ralphm

    I.e. his argument there is that radio usage affects battery a great deal more.

  68. ralphm


  69. dwd

    No, I think larma is right, modulo "significant". Transmitting EXI is lower octets, and while it'll probably cost the same, it'll be less power. Additionally, receiving EXI might come in under radio limits, though I have no idea if my knowledge on FACH etc is useful post-3G.

  70. dwd

    SO it'll make a difference, though whether this becomes significant or not I can't tell. My gut feeling is probably not.

  71. larma

    I think EXI is more important from the save energy perspective than from the save bandwidth/data perspective. Significant might be a bit to much, but at least measurable

  72. larma

    It also depends on the type of messages you send around. If it's only messages with a body, then impact is far less than if you include messages like receipts and so on that can profit much more (relatively spoken) from EXI

  73. dwd

    ‎[23:24:25] ‎dwd‎: True, if you were shipping complex and large xml around like atom, it might make a difference. But EXI is most useful for reducing processor and memory load, not bandwidth.

  74. dwd

    But I don't think that's going to be very significant at all for a mobile handset - there I was meaning in terms of IoT and embedded devices.

  75. dwd

    Still, by all means measure it.

  76. larma

    Maybe we should just try it out, I am at least rather certain that it won't hurt ;)

  77. dwd

    Well, aside from fixing schemas, etc.

  78. larma

    dwd: but using schema is optional for EXI, no?

  79. dwd

    Sort of. My (poor) understanding was that using EXI without strict schemas was a bit pointless.

  80. Kev

    Isn't it ~=deflate at that point?

  81. dwd

    Well, only if you're using deflate.

  82. dwd

    And if you're using deflate, then you have a compression oracle, so...

  83. dwd

    You're also probably outweighing any benefit, CPU-wise.

  84. larma

    Wasn't it somehow learning the "schema" (probably rather qnames) from the actual XML being exchanged? Maybe I'm confusing it with something else. Yes that's probably similar to deflate(xml) but minus the xml parsing (because EXI already takes care of that in an efficient way)

  85. ralphm

    Arc has done a lot of work on EXI, so you may want to ask him.

  86. larma

    I talked with him a few months ago, so most of my EXI knowledge is actually from him ;)

  87. dwd

    EXI has two switches - strict schema and deflate. With strict schema both ends will need to agree on the schemas used, and any additional attributes and extra bits in other namespaces (for example) are removed.

  88. Zash

    Was there a mode that's equivalent to sending generic XML packed in C-like structs?

  89. dwd

    Zash, That's sort of what EXI does, I believe, though the element tags etc are given identifiers based on the schema most of the time.

  90. moparisthebest

    Arc, simple, because only QUIC, not SCTP, has been blessed by "the browsers", so only it has a chance to work into the future :'(

  91. flow

    "With strict schema both ends will need to agree on the schemas used, and any additional attributes and extra bits in other namespaces (for example) are removed." Wasn't there a, potential configurable, fallback to schema-uninformed mode if the schemas are not available?

  92. Ge0rG

    What would be wrong with the client informing the server on its schema on session setup?

  93. pep.

    moparisthebest, and by "the browsers" you mean google? :)

  94. Ge0rG

    Google Chrome and Google Firefox.

  95. moparisthebest

    well I meant chrome and firefox but yea that's a different thing to cry about

  96. pep.

    Oh and Google Brave! The privacy-minded browser that's chained to a block

  97. ralphm

    moparisthebest, I think what I wrote above as the reason is a lot more plausible.

  98. dwd

    Also not entirely clear what SCTP would buy us here. It does allow multiple endpoints at each end of a VC, but I don't think it'll allow for sudden network switching.

  99. dwd

    ANd the startup cost is roughly the same as TCP, unlike QUIC.

  100. moparisthebest

    also no encryption built in with SCTP, is there even encryption defined to go over it?

  101. Zash


  102. Zash

    How's mptcp these days ?

  103. moparisthebest

    I think it's equally dead for the reason ralphm said, too many middleboxes don't do IP, they only do UDP and TCP, so those are the only protocols allowed to exist in the future

  104. Zash

    MPTCP was supposed to be compatible with TCP

  105. larma

    SCTP over dTLS over UDP?

  106. larma feels like reconstructing the WebRTC stack 😀

  107. moparisthebest

    so I guess that was a "no" to my original question "has anyone started specifying XMPP-over-QUIC" ?

  108. moparisthebest

    the hardest part will be defining how to pronounce XoQ

  109. ralphm

    AFAIK, nobody has done this yet, and I nudged dwd with a suggestion to work on it with him around the Summit.

  110. Ge0rG

    What kind of standardization is needed for that?

  111. ralphm

    Well, I think the best approach would be an IETF Draft. A few words on TLS already done at the transport layer, some on session reestablishment. I need to look into it in detail.

  112. ralphm

    For comparison, look at https://tools.ietf.org/html/rfc7395 that was done for the WebSocket binding.

  113. ralphm

    Then, if you want to go fancy, there could be another spec on how you might make use of the connection for multiplexing media streams with Jingle, TURN.

  114. dwd

    FWIW, I don't think this is a Summit task.

  115. ralphm

    dwd: I don't think it is a Summit task. It is something we could maybe discuss, figure out, whatever, around the Summit, while there's a high bandwidth connection in place.

  116. Ge0rG

    does that actually require a high-bandwidth connection?

  117. dwd

    Ge0rG, Only until we have QUIC.

  118. Ge0rG

    Are we speaking of the same kind of connection?

  119. moparisthebest

    here is an example of another protocol over QUIC https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07

  120. moparisthebest

    but we probably want to consider if we want to take the same approach as https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07#section-3.5 or whether we should just throw up our hands and define XMPP-over-HTTP/QUIC

  121. jonas’

    where’s the example which abolishes quic?

  122. moparisthebest

    at this point I'd probably just lean towards "indistinguishable from HTTP" to head off problems down the road

  123. moparisthebest

    but maybe you don't and if you are faced with such a crap network you do XMPP-over-BOSH-over-HTTP/QUIC and cry in a corner

  124. Zash

    I don't wanna live in a world where everyhing is HTTP

  125. moparisthebest

    There are no Websockets over http/2, I'm pretty sure there ane no Websockets over http/3 either

  126. moparisthebest

    I don't think any of us want to live in that world Zash , yet here we are :(

  127. edhelas

    can't wait for QUIC over XMPP

  128. MattJ

    over pubsub you mean?

  129. edhelas

    let's wait for full Pubsub support in the XMPP servers first

  130. dwd

    moparisthebest, HTTP/2 doesn't have websockets?

  131. moparisthebest


  132. Zash

    Doesn't ALPN remove the need somewhat? Like, why talk something over ws when you can talk something directly?

  133. jonas’

    browsers still don’t allow you to open arbitrary sockets, do they?

  134. Zash

    Of course not

  135. moparisthebest

    1. you are running in a web browser 2. you want to pretend to be a web browser because evil middleboxen

  136. Zash

    1. I'm not. 2. I don't.

  137. dwd

    moparisthebest, RFC 8441 BTW

  138. moparisthebest

    dwd, ah awesome, that's newer, I *suppose* that might *just work* over http/3 too

  139. jonas’

    if we accept that the world is going to be *-over-HTTP anyways, why keep bothering with XMPP?

  140. Zash

    give up and join matrix?

  141. jonas’

    would make much more sense to drop that layer of complexity and do something with JSON-over-HTTP directly.

  142. moparisthebest

    HTTP doesn't solve the problems that XMPP does?

  143. jonas’

    sure, but you can solve those problems on top of HTTP obviously, and you can do that easier than by wrapping XMPP in Websockets over HTTP

  144. jonas’

    easier = with less technology stacked on top of each other

  145. moparisthebest

    JSON vs XML is a different discussion, JSON isn't any more closely tied to HTTP than XML is it?

  146. pep.

    it isn't. it also isn't more closely tied to browsers than XML is

  147. jonas’

    also not the main point I’m trying to make

  148. jonas’

    JSON vs. XML does indeed not matter

  149. jonas’

    question is why bother with XMPP if we’re going to squash it over HTTP either way?

  150. moparisthebest

    I'm not sure I buy your argument yet, that you can do it easier with plain HTTP than XMPP over HTTP

  151. jonas’

    for certain definitions of plain HTTP

  152. moparisthebest

    just to be clear definition-wise, QUIC replaces TCP+TLS, http/3 is HTTP over QUIC, and we could end up doing XMPP over QUIC *and/or* XMPP over http/3 (and the latter could be BOSH, Websockets, or something new)

  153. moparisthebest

    sorry, http/3 is http/2 over QUIC

  154. jonas’

    did I mention that’s all awful?

  155. Zash

    everything is terrible

  156. jonas’

    I’m going to start make dinner before this ruins my night

  157. moparisthebest

    *all* of it's awful?

  158. moparisthebest

    at least QUIC replacing TCP+TLS doesn't seem bad to me

  159. dwd

    Seems fine to me too.

  160. Zash

    Something something potato farming

  161. pep.

    Zash, so you can throw potatoes at Google?

  162. moparisthebest

    it has plenty of other upsides, but maybe the best for everyone is connections surviving network/ip switches

  163. Zash

    pep., strategic ballistic potato warfare?

  164. jonas’

    see, QUIC isn’t even an RFC yet

  165. moparisthebest

    it's pretty close, and widely implemented/deployed :)

  166. jonas’

    and that everyone is talking about building stuff on it is plain running behind google and chromium to not fall perceivedly behind

  167. jonas’

    widely ipmlemented/deployed and not through IETF process is a red flag to me

  168. moparisthebest

    some significant percentage of XMPP isn't an RFC either

  169. jonas’

    especially if driven by a large commercial entity

  170. moparisthebest

    it is through an IETF process

  171. jonas’

    "through" as in "passed completely"

  172. Zash

    Simliar to HTTP/2?

  173. dwd

    The concern is mostly whether, if Chrome and the IETF diverge, will the IETF's draft get "correctd" or the Chrome implementation.

  174. moparisthebest

    jonas’, no I'm not talking about the old/dead google/quic, but the widely implemented/deployed ietf/quic

  175. jonas’

    moparisthebest, the core of XMPP is IETF-realm, and everything on top of that is XSF-realm, which as kind of a fork of some IETF workgroup is okay in my book. it’s an open process with controls to prevent a single company from taking over.

  176. jonas’

    moparisthebest, ietf/quic, as per the expired draft?

  177. jonas’

    a draft which has expired for two and a half years now

  178. jonas’

    anyways, dinner

  179. Zash

    Which draft?

  180. moparisthebest

    jonas’, https://quicwg.org/ "QUIC is an IETF Working Group that is chartered to deliver the next transport protocol for the Internet." I don't see what you are worried about exactly

  181. Zash

    https://tools.ietf.org/wg/quic/ most of those look fairly recent

  182. dwd

    Ah, I think jonas’ was looking at draft-tsvwg-quic-protocol, which died (and was shelved, IIRC, until HTTP/2 was done).

  183. Zash

    But HTTP is frozen in time!!!!1!!

  184. !XSF_Martin

    That's a good album.

  185. !XSF_Martin starts humming the 'redneck stomp'

  186. moparisthebest

    not good https://sha-mbles.github.io/

  187. !XSF_Martin

    Sha1 is used for scram in prosody, right?

  188. MattJ

    In XMPP

  189. dwd

    SHA-1 is used in SCRAM-SHA-1, yes.

  190. dwd

    Time to bump the MTI again...

  191. Zash

    SHA-1 broken doesn't mean that HMAC-SHA-1 is broken

  192. !XSF_Martin

    Is it possible to upgrade to something not yet broken?

  193. Zash

    Nor that PBKDF2 is broken

  194. !XSF_Martin

    > SHA-1 broken doesn't mean that HMAC-SHA-1 is broken So scram-sha-1 is not affected?

  195. Zash

    !XSF_Martin: Not easily

  196. dwd


  197. jonas’

    it isn’t, because SCRAM doesn’t care much about collision resistance. also, love the analogy of Matthew Green there

  198. dwd

    More particularly, I do not know that HMAC-SHA-1 is safe (whereas I do know that HMAC-MD5 is safe, or rather, as a cryptographer said over coffee, "Yeah, I think that's still safe though you'd be insane to use it of course")

  199. Zash

    Practically it's nontrivial to upgrade

  200. dwd

    It'd be nice if we had a forced password update protocol.

  201. dwd looks meaningfully at XEP-0388

  202. !XSF_Martin

    > Practically it's nontrivial to upgrade That's better than impossible. 🙂

  203. MattJ

    Zash: other way around. You mean theoretically it's nontrivial to upgrade. Practically speaking, I doubt most clients will blink if you one day just offer PLAIN

  204. Zash

    MattJ: No, they will refuse

  205. MattJ

    Because it's 2020 now and software is secure?

  206. MattJ

    Did I miss this?

  207. Zash

    Conversations does this

  208. MattJ

    Any others?

  209. Zash


  210. MattJ

    Conversations can be fixed (to do something sensible)

  211. Zash

    Allowing downgrade attacks ?

  212. MattJ

    Which would be SASL2 of course

  213. Zash


  214. moparisthebest

    I wonder what it means for git/hg

  215. Zash

    They already started looking at replacing sha1

  216. jonas’

    I think they need to hurry up

  217. moparisthebest

    > linus said attacks like that on git are harder because the hash input is tagged with a type/length, so the collision would have to be the same length

  218. moparisthebest

    so "it's probably ok for now" but not rock solid

  219. !XSF_Martin

    A sealife habitat?

  220. dwd

    MattJ, Quite a few spot if you remove SCRAM-SHA-1 suddenly.

  221. dwd

    MattJ, But yeah, SASL2 and a password reset task would be awesome. Except clients would still try to use SCRAM-SHA-1.

  222. Ge0rG

    there is still PLAIN. But you can't downgrade secure clients.

  223. moparisthebest

    if PLAIN is always good enough for HTTP...

  224. moparisthebest ducks and runs

  225. dwd

    Goodness no. The web world uses bearer tokens, which are entirely different.

  226. Ge0rG

    Say what? Authorization basic can't hear you