XSF Discussion - 2021-05-13

Almost board meeting time

Who is here?

o/

Okay so we technically have quorum

We really need to move beyond having half the board every week

Ralph?

I'll send an email about some stuff, and this

Thanks. If we need to move to monthly, longer meetings so be it. Its just frustrating to set time aside every week and most of the time we don't have attendance

Ooops. I am here, too, just distracted by Something Interesting I FOund On The Internet.

Ok so, agenda?

Agenda, I cannot help with. But:

Fiscal sponsorship update.. CoC..

* Financial Host stuff: I think we're waiting on Peter, though Sam has been pushing forward with draft policies etc.

There is a pending PR for review

* CoC: I'm just coming to the end of my notice period, which has been pretty disruptive (and the job hunting bit beofrehand), so will get back onto this and the associated Provacy Policy I think we should have.

I'd also like to work out what the next steps are on the CoC stuff

:)

Thanks!

On a personal note, I will be changing employer at the end of the month. As part of this change, I'm dropping to 4 days a week, and I'm aiming to generally use that "extra" day for XSF and OSS stuff.

Congratulations :)

Nice

Ok, aob?

No, though I do have some thoughts/research on CoC I'd like to discuss.

I think that was everything

Go ahead

Primarily, we previously talked about a CoC based aorund positive behaviour we wanted to see. However, the research I've managed to do so far actually recommends against this.

This is somewhat to my surprise, to be honest.

Why is that?

The argument is that it is easier for a bad actor to claim their behaviour is, for exampe, respectful ("But they're just deliberately taking it badly") than to argue it is not, for example, an ad-hominem attack.

I totally get that. But do we really want to be in a position to parent bad actors?

No.

I'm merely saying that Codes of Conduct seem a lot more complicated than i'd hoped, and opnions seem generally divided on how to write them.

100%

Anyway, it seems that any code of conduct we put in place is very likely to upset a bunch of people, and not only the people whose behaviour would be affected by a CoC.

I've seen advocates of both styles. I can't claim to know the best option - I would personally prefer a positive-leading one, but I understand the concerns with that. My concern with a list of bad behaviours is that there is a potentially infinite list of such behaviours.

That's not to say we shouldn't put in place a CoC, but we need to manage the entire process carefully.

https://www.contributor-covenant.org/ (originally posted by Sam) seemed good to me at a first glance, it struck me as a decent balance of both

Yes, but it's been a focus of political ire as well. Broadly adopted as-is by the Linux kernel community, and that met with quite some resistance.

There's also the Debian one, which seems to have been mostly controversy-free, but might not have been as effective as people would have liked.

The Debian one controversy-free? :)

Anyway, I'm broadly leaning toward something like the FLOSSUK one - https://www.flossuk.org/about/code-of-conduct/- that seems to state aims in terms of positive behaviours, and then gives a non-exhuatsive list of bad behaviour.

Not from the mailing lists I'm on

I've yet to see a CoC adopted at any org without controversy

But you know, we can be the first :)

MattJ, We can hope.

Sounds like we have reached the end of the meeting?

Yes, sorry. Kind of rambling on a bit.

These are important conversations

But it sounds like we've come to a close so

+1w?

Sounds good.

Things the virtual gavel

Bangs

I have been driving so I'm on voice and put

Input

I also serve on the board of the neighborhood community garden which meets every week at 10:00 a.m.! 😅

Meetings here are far less exciting than XSF board meetings. I'm the youngest member of this board by about 20 years

so I accidentally discovered a DNS-only DOS against ejabberd, but also, my guess is, most other XMPP servers

so here's the question, on outgoing S2S, if you don't *receive* anything over the connection, how can you be sure you are connected to what you should be ?

do you... try to receive data on the connection and if you receive anything at all, abort it and move onto the next SRV record ? or what ?

how do you avoid the case where someone who only controls your DNS, or someone who only controls a route between you and 1 of the SRV records, can entirely block your ability to connect to the remote domain ?

Mmm, that's not really preventable, is it? :)

If they control it they can drop DNS/SYN

yea possibly DNS isn't able to be worked around, what about the second case though ?

you have 2 SRV targets in different locations, an attacker who controls only the route to the lowest priority one shouldn't be able to prevent you from falling back to the second, right ?

right now, with ejabberd, and I suspect most other servers, if you redirect the first to an HTTPS server for instance, the second is never attempted

(I accidentally broke all incoming federation from ejabberd servers to mine this way :))

c2s doesn't suffer from this problem because it's bi-directional

But C2S does suffer the same problem.

If you can drop someone’s connections, you can drop someone’s connections.

Or I’ve not understood properly.

dropping is easy, you can fallback to the next SRV record

When, though?

and if you've validated the TLS properly, and get valid XMPP, you are connected to a c2s port

If you connect and authenticate to the server ok, and then it drops, you shouldn’t drop back to the other SRV should yoU?

how do you determine if you've connected to a valid s2s port though

It doesn’t matter, does it?

If your transit is malicious, it will allow enough through to cause you to authenticate, and then terminate.

(Which is much easier with C2S than S2S, because of rountrip counting)

And because you had a live connection, you won’t fallback.

So even “If I didn’t manage to authenticate, fallback” doesn’t save you there.

what's the point of SRV records if having the first one misbehave blocks you from trying the rest ?

What does ‘misbehave’ mean though?

so maybe it needs some consideration in c2s too "if the connection is "too flakey" (todo: define "too flakey") fallback"

misbehave as in anything someone not in control of the TLS certificate can do

Flakiness protection is horrible, but it’s what you’d need here, yes.

(And the same for S2S)

We actually do have protection against this sort of thing for our X2X support, but less so for S2S.

(Because, as you noted, bidirectional)

so what's a start for defense against this in S2S? only what I mentioned? > try to receive data on the connection and if you receive anything at all, abort it and move onto the next SRV record ?

afk sorry

I guess that brings back my question from the other day, do any XMPP servers in the wild ever send anything over normal (non-bidi) incoming S2S connections ?

Except for stream header, stream errors, stream close, and potentially 198 or whitespace... no?

Matt - I saw you removed dwd from Prosody, was that just getting rid of dialback stuff, or you found security issues, or …?

(Or did I misread the release notes)

Only the part that's mostly equivalent to SASL EXTERNAL

Hmm. Is it?

I kept calling it LUA.

Kev: It had a security issue, but we opted to remove it. We don't have any test coverage and poor confidence in it working correctly.

MattJ, I think they only send pre-TLS stuff, after TLS is started it seems even stream errors are sent over the other connection ?

Stream errors always have to be sent over the stream they relate to.

And by "equivalent to SASL EXTERNAL" I mean that it could optionally check your dialback request against the cert and short-circuit it.

It was disabled by default and I don't think I ever saw it used.

I'll have to test again, I swear I saw them being sent over the other one...

Not sure if it was even documented.

I’m not going to say you didn’t see it - but you shouldn’t have :)

moparisthebest, dialback stuff too maybe, in addition to the stuff MattJ listed

if there doesn't exist a way to *request* something back on the same connection (that won't terminate it, like a stream error), maybe that's the solution

198 can request traffic.

a simple ping, but on this s2s connection

moparisthebest: a solution, but I'm not sure I understand the problem

I don’t think it’s a solution to the proposed problem, if we’re still on “transit terminates your connection as a DOS"

the problem is, once an S2S connection is established, and TLS verified, how do you detect if you are actually connected to an XMPP server, or something else (like HTTPS)

because if you aren't you need to fallback to the next SRV target

If you’re not connected to S2S you don’t get stream headers?

And if by ‘established’ you mean you’ve already authenticated, doesn’t that mean you already know you’re S2S?

the pre-TLS ones ?

The post-TLS ones.

But the pre-TLS ones if you’re doing starttls mean you’re talking to XMPP too.

not necessarily

an evil MITM in front of that target could fake XMPP before TLS, then just redirect traffic from an HTTPS server with the proper certificate

That would be why you bin everything once you start TLS.

(Well, ‘that’ - that you can’t trust pre-TLS in general)

it does protect against accidental misconfiguration, just not active attacks

which is why I suspect this bug has lasted so long in SRV implementations, it's just easier to spot with direct TLS

It's not really a bug, it's just the internet

if your SRV implementation connects, tries to send a stanza, gets an HTTP response and the connection is closed, and it doesn't fallback to the next SRV target, that's a bug

It's suboptimal behaviour, yes :)

You're forgetting the stream header there