XSF Discussion - 2021-03-12

Where is defined how a domain best regards the status of a remote entity, when the federation between the two domains gets disconnected?

Look at the circumstances of the disconnect and then ... do something. Or nothing.

Guus, what do you need that status for?

jonas’ Presence status (are contacts on a remote domain for which federation got disconnected considered offline?) or MUC room occupancy (are they still an occupant of the room?) ✏

going by the bare bones standards and extrapolating from there, presence status should not be affected by a link going down until you run the next presence probe

the next presence probe will then either succeed (yay) or fail to establish s2s (at which point you have a proper type='error' presence you can set) ✏

of course, you may decide to run a bunch of presence probes (e.g. up to 5% of the remote roster entries or something) right away when a federation link dies with abnormalities (such as layer 3/4 errors, <shutdown/> stream error or things like that)

Guus, reverse question: how do you define "federation between the two domains gets disconnected"?

jonas’ the last s2s socket between the two being disconnected, I suppose.

which is interesting if not bidirectional.

yeah, I wouldn’t take any judgement based on that alone -- some domains for example close sockets which aren’t used in a while

jonas’ that's actually what caused me to start thinking about this. Re-connection can occur to a different host, which introduces some nastiness in our implementation.

fwiw, I tend to agree with you - but could not find any documentation on it.

OTOH you may have some situations (we have) where as soon as a link goes down you know it’s disconnected and want to act accordingly.

(Never with ‘real’ S2S though, I think)

> yeah, I wouldn’t take any judgement based on that alone -- some domains for example close sockets which aren’t used in a while I'm not even aware what my server does. Have you set anything in that regard in your prosody?

mdosch, I had a module loaded which does that for a while on s.j.n, but I unloaded it because it was suspect of having a memory leak

but I still see s2s dropping off between crawler runs, so at least some other domains close their s2s when idle

I also see closing of idle connections in my log but I never bothered to check whether it's mine or the remote server doing this. ^^

It's the remote > Session closed by remote with error: connection-timeout (Idle connection)

prosody doesn’t do it by default

siacs, blabber, fu-berlin. Seems to be all ejabberds indeed.

There is one other server that closes s2s to me and then their DNS fails

I often loose presence in the conversations muc due to remote idle timeout. (Ejabberd) and its not reestablished by its own for some time.

If only there was a XEP to discover loss of MUC connectivty.

In theory it should reestablish s2s when needed. In practice...

grep -cE quicksy\.\*Idle /var/log/prosody/prosody.log :( 70

That seems to be… a lot.

mod_s2s_keepalive didn't help, I suppose it doesn't affect the remote idle timeout only mine

The real question is why re-establishing a new connection fails.

True ,but on my side of the logs there is nothing.. Or maybe I try debug first.. Let me check

I mean why would the old, idle connection survive under circumstances where a new connection can't be established?

In theory, you should be able to throw away S2S at any point without any user noticing.

In theory :)

Its only conversations muc, I will look

COM8: Mar 12 12:15:49 s2sin5609d9a60bf0 info Incoming s2s stream xmpp.uwpx.org->chat.diebesban.de closed: Your server's certificate has expired

jonas’: Sell o.j.n

:)

Is it a good thing that, where with dialback you either got bi-directional connectivity when it was done, with SASL EXTERNAL you can easily end up with only working connectivity in one direction?

mdosch: Yes, know about that but due to the current situation I do not have access to my server :(

Oh.

Jep...

Zash: Oh, you didn’t even always get bidirectional connectivity with dialback :D But I grant it was much harder to end up with one-way stuff.

Oh I may actually have either one-way or zero-way dialback with someone.

Eh, excuse to push for moar XEP-0288 😀

Can ejabberd do it?

5 second search turns up no evidence that it does

Yeah, sorry i was lazy, i know i could have just searched😞

Another thought, would anyone be interested in a weekly "office hours" session where projects can talk about whatever they want? Eg. a recent improvement to your client, or a year in review, or "one weird trick for making a living in open source" or whatever it is your project does? I'm trying to find ways to make the community more engaged across projects and thought it might be good for engagement

Might send out a sign up form and just see if anyone signs up for it.

Something like the monthly(?) xmpp meetup?

There's a monthly xmpp meetup? (but yes, I guess so)

Sam: https://wiki.xmpp.org/web/Meetups/Berlin

I'd say this is different just by virtue of being online first and not focused on any geographic area. Probably shorter too.

used to be a physical gathering pre-pandemic, then a German jitsi call, but also held in English when there are non-natives

At several jobs I've been at we've had a weekly lunch-and-learn sort of thing. You sign up for a slot and can present about whatever you want for a few minutes. I've learned a little about a lot of interesting things from them, and think something similar might benefit this community.

Ah, the lunch break plus plus thing.

(added the Berlin one to my calendar though, thanks)

Although their blog doesn't want to load, so but we'll see.

I got access to a BigBlueButton instance recently and am looking for excuses to try it out and see how it compares to Jitsi too, so this may just be an excuse to use that :)

Sam: organize one, see if there's interest.

Guus: that's what I'm doing here :)

Maybe it's worth just sending out a signup form instead of asking though

ah, yes.

In context of MUC's 'ghost users' handling (https://xmpp.org/extensions/xep-0045.html#impl-service-ghosts): > To help prevent ghost users, a MUC service SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user Is there harm in not explicitly checking if the error is in relation to a stanza that the service has previously sent to the user (by considering the user a ghost when a stanza is being parsed that has the user's address in the 'from' attribute, and the user is an occupant of the room that the stanza has been addressed to)?

Yes, if you allow ‘normal’ errors to be counted as ‘can’t reach’ errors. No if you ensure you only count ‘can’t reach’ errors, I think.

I'm trying to see if I can prevent doing archive lookups to see if the error matches something that was outbound - stuff like that, but I'm also keenly aware that making assumptions could open a vector for abuse.

There is also the situation of PM errors ;)

Kev: what are the legitimate cases where an occupant could send an error to the room or to another room occupant and not get kicked?

I'm only considering the errors listed in the XEP: "<gone/>, <item-not-found/>, <recipient-unavailable/>, <redirect/>, <remote-server-not-found/>, and <remote-server-timeout/>"

Ge0rG: “I can’t handle this type of message”, “I don’t allow PMs from people not in my roster”. Anything the client likes, really.

(which is what Kev means with 'can't reach' errors, I think)

There is also a list of potential error causes at the bottom of https://xmpp.org/extensions/xep-0410.html#performingselfping

Ge0rG I'm talking about receiving errors on the service-side. What you refer to would be receiving errors on the client side, I think.

Guus: well, my errors also contain s2s errors

I'd love to have more explicit lists of error reasons.

I'm not following how that's relevant for the service-implementation that I'm working at. I don't see how it would be affected by those errors (which would flow from the local domain of the client to the client, and never touch the target MUC service, I tihnk?)

Guus: all MUC interactions go through the MUC service

so you have s2s in all directions

Guus: I send a PM to you. The MUC server routes it, but can’t reach you, it generates an error. That error could be used to bounce you.

And is fine to do so, I think. It doesn’t matter what stanza caused us to realise we can’t reach a user, we can’t reach them all the same.

I'm confused - are we just agreeing with each-other here, or are you pointing out something that I missed?

I'm basically asking if it's safe to consider an occupant 'ghost' if a message with it as the 'from' arrives at the MUC service for processing, when it has one of the aforelisted errors.

I’m agreeing that’s safe, whether it’s a MUC message or MUC PM as long as it’s that type of error, yes.

if your PM was to be forwarded by the service to me, but the service can't reach me, it'd bounce (reverting the to/from addresses), where it'd be processed matching what we described above, I think.

yey for elaborate agreement. 🙂

I note that where the MUC server is collocated with an IM server, you can’t use other bounces for the recipient, it has to only be bounces ‘to’ the MUC service.

So the “arrives at the MUC service” bit of your text is important to be taken literally, not just “arrives at the server hosting the MUC service”.

oh, I didn't even consider that scenario.

but, to entertain the thought: why wouldn't any connectivity-related error be usable?

(if the MUC service and XMPP domain are colocated)

You’re virtual hosting good.im, muc.good.im, bad.im. I have bad.im blocked by my server, and I’m in a MUC on muc.good.im. A user on bad.im tries to send me a stanza.

ah, more scenario that I didn't take into account. We can not host more than one primary domain.

S2S fails to my domain from bad.im, generates a bounce. That bounce mustn’t be used to remove me from a MUC on muc.good.im

Doesn’t matter, does it? It still applies - I’m blocking just.im, but not blocking muc.just.im :)

fair - but is that even a real-world applicable scenario?

(still, I wasn't going to implement the processing like that anyways, but I'm grateful for understanding your reasoning)

I don’t know. Whenever I’m confident a thing won’t actually happen in the real world...

beentheredonethatregrettedit

But my first implementation was on the other end of the spectrum. It would drop a user only from the one room that the bounce is addressed at. I was considering if I could drop the user from all rooms. ✏

There’s always a danger that someone uses an inappropriate error for a non-remote-server bounce. But it *should* be safe enough.

Although I have a bad feeling about item-not-found

And recipient-unavailabel for that matter.

your implementation doesn't do this?

I don’t recall, it’s quite possible we do.

I think if you want to be safe, ensure that the error is sent to a room the user is in.

So that e.g. mediated invites don’t cause funny behaviour.

yeah I'm doing that

Maximum safety is only kicking from the room that the error is for, but scenarios where that matters are looking a bit stretched.

Hmm, actually.

I think you might want to just stick to the MUC that the error is for. And if you want to ensure other MUCs do the right thing, trigger a ping from the other MUCs.

that's what my first implementation does (only kick from the addressed room)

I’m thinking about scenarios where a stanza from a room crosses paths with the user leaving the room.

I'll keep things simple for the first implementation anyways.

Optimizations can be applied later.

Thanks!

Who has access to the XSF Calendar? dwd or Guus maybe?

I do. What do you want changed?

Sam: ^

I was hoping I could get the office hours added: https://wiki.xmpp.org/web/XMPP_Office_Hours

(also someone on the comm team was curious who had access)

(also, thanks Daniel for stepping up and taking the first slot! I was concerned my current talk ideas would be far too boring, but A/V calls with OMEMO will be a great one to kick things off!)

Sam, I promise I'll do a talk on Messaging In A Pandemic, as soon as I've completed this project at work. But thanks for organizing this.

Sam, And also for this: https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/?include_text=1

(Which, folks, is in WG Last Call in IETF's kitten WG)

dwd: excellent, thanks!

(both for doing a talk and for advertising the LC, I probably should have requested feedback from this group)

Yeah, I meant to share that on standards@

Sam: starting today?

I'll write something up, sharing it here is a good idea.

ralphm: starting next Friday

oki

(the 19th, I believe)

yes, that's the one. I can add.

Assuming one hour

Yes please

I didn't actually think about a time, but that seems sane

ralphm: you might link the wiki page in the description or "Where" fields: https://wiki.xmpp.org/web/XMPP_Office_Hours

Sam, Your TLS channel binding looks almost embarrassingly simple, but I wanted to look at the OpenSSL APIs for this and see if it's as obvious as it looks. I'll have a handful of editorial fixes for you.

dwd: Thank you! It's almost not even worth writing an RFC for. The thing about TLS exporters is that this is basically what they already are anyways, all we're doing is registering it with IANA and making up a string.

I think it was, possibly so simple I didn't understand it. Unlike the rest of OpenSSL.

I would almost have preferred if we just got rid of all the old channel binding stuff and say "TLS Exporters are channel binding now, everybody make up your own names for your community" since we don't have to do the algorithm ourself anymore

Hard part (for us, Prosody) would be getting it into LuaSec and then into distros and figuring out how to get it hooked into the right things.

Sam: looking good like this I think?

Irks me to have to do `if TLS.version == 1.3 then foo else bar` 🙁

Great idea, BTW

LGTM, thanks for adding it!

Sam, can you not just make message styling your first talk? or does this take more preperation

Daniel: I could if you don't want to be first, I just don't have it fully prepared yet (and also a lot of people really hate message styling, I didn't want the first one to be something a lot of people don't care about or actively dislike)

A/V and OMEMO sounds a lot more interesting to me too, so I think it would be a good one to start with

I don’t mind being first. but i rather hear something about message styling than an intro to xmpp tbh

Sam: FWIW, it appears that you also have write access to the XSF Google calendar.

Fair enough; maybe I'll swap those around and save that one for a day when nobody else puts something on

ralphm: huh, TIL, sorry to bug you for it then

Gladly done, no worries

as far as i understood it the target audience is mostly people in the XMPP-verse, no?

I think that can change from week to week, it's whatever the presenter wants to talk about really.

Zash: re channel binding, I tend to agree about the TLS version. The problem is that I'm almost certain that certain old ciphers in TLS 1.2 won't actually create unique keying material. If you're confident that you can avoid those, you can likely use this on TLS <1.3, I just don't know how to provide good advise for doing so safely.

Which "this" is that?

You can use this channel binding mechanism, I mean

dwd: RE your channel binding feedback (sorry, when I cleaned out my roster a while back I lost everybodies JIDs): would you prefer a separate "Use with Legacy TLS" section, or just moving that one paragraph into the security considerations? I could see it going either way

(or maybe a "Use with Legacy TLS" section that's a subsection fo "Security Considerations"? I dont' know what's normal)

I would personally seperate out the legacy TLS stuff into its own section. Could be a subsection in Security Considerations or a new section or a part of 2.1., I'm not fussed.

Also, dwd@dave.cridland.net as always.

Will do; thanks

dwd, if you have a moment, could you look at why I can't reach you from zash.se?

I have no idea what's going on with my S2S, actually. Half a dozen sites I can't reach ATM, but I have zero time to go look properly.

😕

> I think that can change from week to week, it's whatever the presenter wants to talk about really. OK. Let's see where this will lead us then. Personally I would really like to have a thing where I can meet other XMPP developers and workshop new ideas. We have other events that have a more broader audience like the XMPP meet-up. Those can be fun as well but it's not exactly a place where I can get feedback for my new protocol design ideas

Oh I think this would be great for that too; feel free to schedule more general round-table style discussions or new idea presentations

nmap -p5269 nimbus.dave.cridland.net Starting Nmap 7.80 ( https://nmap.org ) at 2021-03-12 16:26 CET Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 3.22 seco

Zash: dwd ^

Hmmm.

There's a security group I've messed up.

Oh, -Pn you'll need, sicne it doesn't (most likely) ping.

Yeah, ports are indeed open (I thought so, since that's how I'm sending stuff...)

Ports. Used for sending stuff since 1300 BC.

Weird, I tried earlier if your not reachable from my server as well and it seems my message didn't go through. Now I looked at my logs and I see this:

Mar 12 16:22:14 s2sout5609d936daa0 info Outgoing s2s connection mdosch.de->dave.cridland.net complete Mar 12 16:34:43 s2sin5609d9cf3bf0 info Incoming s2s stream dave.cridland.net->mdosch.de closed: stream closed Mar 12 16:34:43 s2sin5609da20bd90 info Incoming s2s stream dave.cridland.net->mdosch.de closed: invalid-namespace

I see it get a connection, but then it times out

That's all very weird.

I can telnet-trigger a not-well-formed, so LGTM

oh, so *now* you people are willing to do talks 🙄

Don't say yay before it actually takes place

theTedd, Yeah, sorry. This project I'm doing will generate (at least one) talk, but it's likely to "finish" around 3rd April, currently.

theTedd: don't jinx it

dwd, that wasn't directed at anyone specifically, and in your case emergencies are urgent in nature

mathieui, jinx jinx jinx 😋

dwd: so I can expect to see you go put your name on right now for mid to late April?

Let me get free and clear, and un-burnt-out enough to write a talk. :-)

but you could go ahead and reserve a spot to make it all full :)

nothing gives as much motivation to prepare a talk as a fixed time slot assignment

deadlines make the world go around