XSF Discussion - 2021-04-19

  1. moparisthebest

    anyone know what servers in the wild do when a remote server sends stanzas back over an outgoing-only s2s connection ?

  2. moparisthebest

    that could be a fun vulnerability if they aren't rejected, I'll try to test this soon

  3. MattJ

    goffi: since you're working on ActivityPub stuff, wanted to make sure you're aware of https://socialhub.activitypub.rocks/pub/ec-ngi0-liaison-webinars-and-workshop-april-2021

  4. goffi

    MattJ: thanks, I think I've seen it passing, but unfortunaly it's during my paid job working time, so I can't attend.

  5. dwd

    moparisthebest, There used to be all sorts of cases of servers doing that, and indeed servers not bothering to reject and just processing (sort of XEP-0288 by default).

  6. moparisthebest

    dwd, yea I could see it being an easy mistake

  7. moparisthebest

    so QUIC has bi-directional streams like TCP, but also uni-directional, I'm thinking those should be the only thing normal s2s should be allowed over

  8. moparisthebest

    then you prevent that problem right out of the gate

  9. moparisthebest

    it has the handy side-effect of making multi-plexing s2s and c2s on the same quic port trivial, all new bidirectional streams are c2s, all new unidirectional streams are s2s

  10. dwd

    I don't think there's any security issue with accepting stanzas over an outgoing S2S channel though. It's just an interop problem because some implementations migt ignore them.

  11. dwd

    And there's lots to be said for making S2S bidirectional.

  12. Zash

    I'm thinking it would be good to at least support errors in the "wrong" direction... like what Google did, except, you know, discussing it first and not just breaking spec.

  13. moparisthebest

    an alternative could be to make BIDI required for XMPP-over-QUIC

  14. moparisthebest

    it might or might not be worth doing though, QUIC connections are considerably cheaper than TCP+TLS connections

  15. dwd

    moparisthebest, In terms of connection speed, yes. But the major memory cost of XMPP is in TLS sessions, as I recall.

  16. Kev

    And buffering.

  17. moparisthebest

    from an OS level you are just sending/receiving a bunch of UDP packets on a single port anyway

  18. moparisthebest

    but yes, re: TLS sessions there could be some wins too, since each QUIC connections supports multiple streams over it

  19. moparisthebest

    so if a server has the same cert for a.org and b.org and I have a QUIC connection for a.org already, I can just open another stream over it for b.org

  20. moparisthebest

    so far I have the "server" side done and am working on the "client" side now, I put them in quotes because they both support c2s and s2s so it's annoying terminology wise :)

  21. moparisthebest

    in the end though, should be able to slap it in front of any xmpp server or client and make them speak xmpp-over-quic, and then, the xep

  22. Kev

    This is all very interesting stuff.

  23. dwd

    XMPP/QUIC is definitely in I-D territory, mind.

  24. dwd

    And yes, XMPP/QUIC has a lot of utility in the spaces in which Kev and I seem to end up.

  25. moparisthebest

    I expect so, but no reason implementation and XEP can't come first

  26. moparisthebest

    I don't think QUIC itself is fully finalized yet even

  27. Kev

    Just a word of warning about acting as a proxy to quic - most servers have different expectations on what clients will do than what quic will necesarily support. I *think* it should be ok if a client treats the quic connection like tcp with possibly better failure cases, but if they were to start expecting be able to do things quic can do (like going silent and coming back) it might get messy.

  28. dwd

    QUIC also does things that TCP has no analogue for, like handover and stuff. It'd be really interesting to fully explore this.

  29. moparisthebest

    the most visible benefit I can think of is mobile clients roaming between wifi and lte etc, no reconnections

  30. Kev

    (Whereas a server doing quic natively knows it’s quic and can cope with it. Hopefully)

  31. Ge0rG

    shouldn't handover be transparent for a socket user like an xmpp server?

  32. Kev

    moparisthebest: Yes, there are definite benefits to be had here. There are also some possible drawbacks to a proxy approach, which I’m flagging just so they’re thought about, rather than to suggest you should stop what you’re doing.

  33. moparisthebest

    in my current implementation, both the client and the server thinks their doing TCP, and will do TCP things, it's just actually doing QUIC over the network

  34. moparisthebest

    in my current implementation, both the client and the server thinks they're doing TCP, and will do TCP things, it's just actually doing QUIC over the network

  35. moparisthebest

    so the specific case of going silent and coming back should work fine I think, the quic proxy will just keep the same TCP connection open to the server

  36. Kev

    I’m thinking, for example, that both ends keep their TCP open while the QUIC goes away. Then the server terminates their TCP for unresponsiveness. Then the QUIC comes back. The client-side proxy then gets told over quic that the connection has gone. Then the client gets told their TCP has gone. Then they reestablish (through the proxy, but costing as many roundtrips as the normal setup would be, plus the time for the original connection to be told to kill over QUIC.

  37. Kev

    Sorry if that was horribly incoherent.

  38. moparisthebest

    ah yes, no I got it

  39. moparisthebest

    on one hand (temporary connectivity loss) timeouts could just be extended, but also they could have hopped to a quic-blocking network, in which case disconnecting and reconnecting (might end up reconnecting over TCP) is the right thing to do

  40. Kev

    I only have half-baked thoughts, rather than anything useful, on this at the moment :)

  41. dwd

    Kev, FWIW, I think a proxy is a useful way to start exploring how a binding might look. Ultimately, though, we'll need servers and clients to natively support the binding, otherwise as you say various weird mismatches will make things go awry.

  42. dwd

    Kev, And indeed, a proxy is almost by definition only half baked...

  43. moparisthebest

    I certainly expect the code+spec to change quite a bit before finalization, but might as well get something going

  44. Kev

    Yes, a proxy (pair) is entirely a sensible (probably most sensible) way to start investigating this. I couldn’t be happier that moparisthebest is looking at it. Please don’t take my comments as suggesting it’s not valuable.

  45. moparisthebest

    the nice thing that enables playing around is if quic-connections fail for any reason, good clients and servers will fall back to TCP

  46. moparisthebest

    at the moment if everyone implemented quic, there are even base protocol differences between the libraries, because quic itself isn't finalized

  47. dwd

    moparisthebest, _xmpp-client._quic....?

  48. dwd

    I am rather beginning to wish we'd gone the _xmpp-client._tls... route now for symmetry.

  49. moparisthebest

    I'm hoping not... srv2/whatever-its-called-now would cover quic + all previous connection methods

  50. dwd

    Oh, I keep forgetting that exists.

  51. moparisthebest

    it should let us advertise+prioritize websocket, starttls, tls, quic, $new-thing-here in 1 DNS query/response

  52. moparisthebest

    I haven't gotten this far yet, other than vague thoughts

  53. moparisthebest

    but if we have to stick (or start) with regular SRV I guess for consistency-sake it'd be xmpp-clientq._tcp >:D

  54. Zash

    `_tcp` ... makes no sense

  55. jonas’

    ITYM _xmpp-clientq._udp

  56. moparisthebest

    could do yea

  57. jonas’

    s/could/must/ I guess

  58. moparisthebest

    the problem (and this is a REALLY STUPID PROBLEM) with anything other than _tcp and _udp is crap DNS web interfaces that only support those 2

  59. jonas’

    what else would you put there?

  60. Zash


  61. jonas’

    quic runs on top of UDP

  62. jonas’

    not next to

  63. jonas’

    so _udp is the right thing here anyway

  64. Zash

    Stupid DNS web interfaces gonna be stupid.

  65. moparisthebest

    yep it'd make more sense than _tcp

  66. moparisthebest

    and dumb web interfaces should be able to handle it

  67. jonas’

    stupid DNS web interfaces are the IP middleboxes of DNS

  68. moparisthebest

    on a related topic... nothing currently does s2s-over-websocket does it ?

  69. Zash

    Maybe Google et all can be convinced to put HTTP/4 directly on top of IP, then maybe we'll finally be able to flush out all those middleboxes

  70. moparisthebest

    I think they gave up on that when they chose UDP for QUIC Zash

  71. moparisthebest

    I *think* the answer to s2s-over-websocket is: 1. nothing does it 2. because there is no way to discover support sound right?

  72. Zash

    Nice things. Can't have them.

  73. jonas’

    moparisthebest, I think the answer is why would you even consider doing such a thing ;)

  74. Kev

    There’s limited value in S2S over websocket, I think.

  75. moparisthebest

    I guess I'm asking... other than lack of discovery support, is there a reason *not* to do s2s over websocket?

  76. jonas’

    moparisthebest, why bring an HTTP stack into something where TCP (or plain QUIC) is sufficient?

  77. moparisthebest

    the value is just... another way to connect I guess

  78. moparisthebest

    yet again, crap networks with crap restrictions

  79. jonas’

    I think those are much less relevant for s2s

  80. Zash

    Don't host your server there then

  81. moparisthebest

    oh I agree, but some people have to live in say china

  82. jonas’

    websockets won’t save you against the GFW

  83. jonas’

    not for long anyway

  84. moparisthebest

    I guess it'd also allow folks that want phone-battery-eating-p2p messengers to *just use XMPP* :D

  85. Zash

    Just run it over Tor tehn

  86. Zash

    Just run it over Tor then

  87. Zash

    That'll take care of the p2p as well as the battery eating

  88. moparisthebest

    and not be able to communicate with 90% of the xmpp network

  89. Zash

    Do they want to?

  90. Zash


  91. moparisthebest

    idk, why not ?

  92. moparisthebest

    the infamous "user"

  93. moparisthebest

    what do they want? no one knows!

  94. moparisthebest

    long story short though, if a new way to discover $connection-types is introduced to cover quic, tcp, direct tls, I guess no reason to avoid throwing websocket in there? maybe even bosh? s2s-over-bosh should be fun right?

  95. jonas’

    second system syndrome?

  96. Zash

    There are too many connection methods now.

  97. Kev

    I think if s2s over websockt adds no value, it’s better to not speak of it than to distract people.

  98. dwd

    How do you discover which DNS transport to use, though?

  99. Zash

    Easy, just use {Google,Cloudflare}

  100. jonas’

    dwd, that hurt.

  101. moparisthebest

    dwd: dns-over-xmpp is the only choice there

  102. Zash

    But how do you find where to connect to *that*?

  103. moparisthebest

    That's hardcoded

  104. moparisthebest

    Seriously though, I'm not immediately convinced s2s over websocket adds no value

  105. Zash

    Try saying it with even more double negative

  106. moparisthebest

    Ha, I think it could be valuable

  107. dwd

    I wouldn't say that I'm not immediately convinced that S2S over websockets adds no value, myself.

  108. Zash


  109. dwd

    Actually, more seriously, it might make deployment simpler. Getting an XMPP server up and running currently is roughly similar to a mailserver, except that people are usually a bit more familiar with mail routing.

  110. jonas’

    oh no.

  111. jonas’

    but so could doing QUIC + ALPN + multiplexing, which I would prefer over websockets for s2s

  112. Holger

    dwd: `apt install ejabberd`, fix the XMPP domain name? :-P

  113. dwd

    Holger, And figure out SRV, firewalling rules, load balancers, and so on.

  114. moparisthebest

    there are also terrible terrible hosting services now that only expose http load balancing for access

  115. Holger

    dwd: None of those are required if you didn't create an unnecessarily complex environment before installing the daemon ;-)

  116. dwd

    Holger, I mean, for you and me, sure. For average sysadmin experieced with The Ways Of Net but new to XMPP? Hard.

  117. Holger

    In the email universe you have an entirely separate daemon for MAM.

  118. moparisthebest

    my thoughts for xmpp-proxy were, on the inbound side, support all-the-methods, and talk to the backend xmpp server over plain tcp

  119. moparisthebest

    on the outbound side, do the same thing, support plain tcp only for the xmpp server/client, then support all-the-methods outgoing

  120. moparisthebest

    this lets you build an xmpp server and/or client that only does plain tcp, no tls/starttls/quic/websocket/bosh

  121. moparisthebest

    clearly a monoculture where every xmpp thing goes through the same proxy would be terrible, but it would allow retrofitting new connection methods while servers catch up

  122. moparisthebest

    clearly a monoculture where every xmpp thing goes through the same proxy would be terrible, but it would allow retrofitting new connection methods while servers and clients catch up

  123. Sam

    Reminder that tomorrow is the XMPP Office Hours! This week I'm giving an intro to XMPP for new XMPP developers. However, if you're an experienced dev I'd love feedback! https://wiki.xmpp.org/web/XMPP_Office_Hours

  124. emus

    Yes, and with that reminder I would like to ask for a volunteer with access to Twitter to put this into a tweet as well? Would be a great support! https://fosstodon.org/web/statuses/106093870952431363

  125. Sam

    Thanks emus!

  126. emus

    Sure! You do a great setup there!