XSF Discussion - 2021-04-19

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

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

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

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

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).

dwd, yea I could see it being an easy mistake

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

then you prevent that problem right out of the gate

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

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.

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

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.

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

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

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

And buffering.

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

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

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

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 :)

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

This is all very interesting stuff.

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

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

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

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

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.

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

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

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

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

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.

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 ✏

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

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.

Sorry if that was horribly incoherent.

ah yes, no I got it

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

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

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.

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

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

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.

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

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

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

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

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

Oh, I keep forgetting that exists.

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

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

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

`_tcp` ... makes no sense

ITYM _xmpp-clientq._udp

could do yea

s/could/must/ I guess

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

what else would you put there?

What

quic runs on top of UDP

not next to

so _udp is the right thing here anyway

Stupid DNS web interfaces gonna be stupid.

yep it'd make more sense than _tcp

and dumb web interfaces should be able to handle it

stupid DNS web interfaces are the IP middleboxes of DNS

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

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

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

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

Nice things. Can't have them.

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

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

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

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

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

yet again, crap networks with crap restrictions

I think those are much less relevant for s2s

Don't host your server there then

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

websockets won’t save you against the GFW

not for long anyway

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

Just run it over Tor then ✏

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

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

Do they want to?

THEY!!!

idk, why not ?

the infamous "user"

what do they want? no one knows!

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?

second system syndrome?

There are too many connection methods now.

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

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

Easy, just use {Google,Cloudflare}

dwd, that hurt.

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

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

That's hardcoded

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

Try saying it with even more double negative

Ha, I think it could be valuable

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

🤯️

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.

oh no.

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

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

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

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

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

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

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

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

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

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

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 ✏

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

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

Thanks emus!

Sure! You do a great setup there!