-
arc
Almost board meeting time
-
arc
Who is here?
-
MattJ
o/
-
arc
Okay so we technically have quorum
-
arc
We really need to move beyond having half the board every week
-
arc
Ralph?
-
MattJ
I'll send an email about some stuff, and this
-
arc
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
-
dwd
Ooops. I am here, too, just distracted by Something Interesting I FOund On The Internet.
-
arc
Ok so, agenda?
-
dwd
Agenda, I cannot help with. But:
-
arc
Fiscal sponsorship update.. CoC..
-
dwd
* Financial Host stuff: I think we're waiting on Peter, though Sam has been pushing forward with draft policies etc.
-
MattJ
There is a pending PR for review
-
dwd
* 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.
-
MattJ
I'd also like to work out what the next steps are on the CoC stuff
-
MattJ
:)
-
MattJ
Thanks!
-
dwd
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.
-
MattJ
Congratulations :)
-
arc
Nice
-
arc
Ok, aob?
-
dwd
No, though I do have some thoughts/research on CoC I'd like to discuss.
-
MattJ
I think that was everything
-
arc
Go ahead
-
dwd
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.
-
dwd
This is somewhat to my surprise, to be honest.
-
arc
Why is that?
-
dwd
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.
-
arc
I totally get that. But do we really want to be in a position to parent bad actors?
-
dwd
No.
-
dwd
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.
-
arc
100%
-
dwd
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.
-
MattJ
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.
-
dwd
That's not to say we shouldn't put in place a CoC, but we need to manage the entire process carefully.
-
MattJ
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
-
dwd
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.
-
dwd
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.
-
MattJ
The Debian one controversy-free? :)
-
dwd
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.
-
MattJ
Not from the mailing lists I'm on
-
MattJ
I've yet to see a CoC adopted at any org without controversy
-
MattJ
But you know, we can be the first :)
-
dwd
MattJ, We can hope.
-
arc
Sounds like we have reached the end of the meeting?
-
dwd
Yes, sorry. Kind of rambling on a bit.
-
arc
These are important conversations
-
arc
But it sounds like we've come to a close so
-
arc
+1w?
-
dwd
Sounds good.
-
arc
Things the virtual gavel
-
arc
Bangs
-
arc
I have been driving so I'm on voice and put
-
arc
Input
-
arc
I also serve on the board of the neighborhood community garden which meets every week at 10:00 a.m.! đ
-
arc
Meetings here are far less exciting than XSF board meetings. I'm the youngest member of this board by about 20 years
-
moparisthebest
so I accidentally discovered a DNS-only DOS against ejabberd, but also, my guess is, most other XMPP servers
-
moparisthebest
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 ?
-
moparisthebest
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 ?
-
moparisthebest
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 ?
-
MattJ
Mmm, that's not really preventable, is it? :)
-
MattJ
If they control it they can drop DNS/SYN
-
moparisthebest
yea possibly DNS isn't able to be worked around, what about the second case though ?
-
moparisthebest
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 ?
-
moparisthebest
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
-
moparisthebest
(I accidentally broke all incoming federation from ejabberd servers to mine this way :))
-
moparisthebest
c2s doesn't suffer from this problem because it's bi-directional
-
Kev
But C2S does suffer the same problem.
-
Kev
If you can drop someoneâs connections, you can drop someoneâs connections.
-
Kev
Or Iâve not understood properly.
-
moparisthebest
dropping is easy, you can fallback to the next SRV record
-
Kev
When, though?
-
moparisthebest
and if you've validated the TLS properly, and get valid XMPP, you are connected to a c2s port
-
Kev
If you connect and authenticate to the server ok, and then it drops, you shouldnât drop back to the other SRV should yoU?
-
moparisthebest
how do you determine if you've connected to a valid s2s port though
-
Kev
It doesnât matter, does it?
-
Kev
If your transit is malicious, it will allow enough through to cause you to authenticate, and then terminate.
-
Kev
(Which is much easier with C2S than S2S, because of rountrip counting)
-
Kev
And because you had a live connection, you wonât fallback.
-
Kev
So even âIf I didnât manage to authenticate, fallbackâ doesnât save you there.
-
moparisthebest
what's the point of SRV records if having the first one misbehave blocks you from trying the rest ?
-
Kev
What does âmisbehaveâ mean though?
-
moparisthebest
so maybe it needs some consideration in c2s too "if the connection is "too flakey" (todo: define "too flakey") fallback"
-
moparisthebest
misbehave as in anything someone not in control of the TLS certificate can do
-
Kev
Flakiness protection is horrible, but itâs what youâd need here, yes.
-
Kev
(And the same for S2S)
-
Kev
We actually do have protection against this sort of thing for our X2X support, but less so for S2S.
-
Kev
(Because, as you noted, bidirectional)
-
moparisthebest
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 ?
-
Kev
afk sorry
-
moparisthebest
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 ?
-
MattJ
Except for stream header, stream errors, stream close, and potentially 198 or whitespace... no?
-
Kev
Matt - I saw you removed dwd from Prosody, was that just getting rid of dialback stuff, or you found security issues, or �
-
Kev
(Or did I misread the release notes)
-
Zash
Only the part that's mostly equivalent to SASL EXTERNAL
-
Kev
Hmm. Is it?
-
dwd
I kept calling it LUA.
-
Zash
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.
-
moparisthebest
MattJ, I think they only send pre-TLS stuff, after TLS is started it seems even stream errors are sent over the other connection ?
-
Kev
Stream errors always have to be sent over the stream they relate to.
-
Zash
And by "equivalent to SASL EXTERNAL" I mean that it could optionally check your dialback request against the cert and short-circuit it.
-
Zash
It was disabled by default and I don't think I ever saw it used.
-
moparisthebest
I'll have to test again, I swear I saw them being sent over the other one...
-
Zash
Not sure if it was even documented.
-
Kev
Iâm not going to say you didnât see it - but you shouldnât have :)
-
Zash
moparisthebest, dialback stuff too maybe, in addition to the stuff MattJ listed
-
moparisthebest
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
-
Kev
198 can request traffic.
-
moparisthebest
a simple ping, but on this s2s connection
-
MattJ
moparisthebest: a solution, but I'm not sure I understand the problem
-
Kev
I donât think itâs a solution to the proposed problem, if weâre still on âtransit terminates your connection as a DOS"
-
moparisthebest
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)
-
moparisthebest
because if you aren't you need to fallback to the next SRV target
-
Kev
If youâre not connected to S2S you donât get stream headers?
-
Kev
And if by âestablishedâ you mean youâve already authenticated, doesnât that mean you already know youâre S2S?
-
moparisthebest
the pre-TLS ones ?
-
Kev
The post-TLS ones.
-
Kev
But the pre-TLS ones if youâre doing starttls mean youâre talking to XMPP too.
-
moparisthebest
not necessarily
-
moparisthebest
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
-
Kev
That would be why you bin everything once you start TLS.
-
Kev
(Well, âthatâ - that you canât trust pre-TLS in general)
-
moparisthebest
it does protect against accidental misconfiguration, just not active attacks
-
moparisthebest
which is why I suspect this bug has lasted so long in SRV implementations, it's just easier to spot with direct TLS
-
MattJ
It's not really a bug, it's just the internet
-
moparisthebest
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
-
MattJ
It's suboptimal behaviour, yes :)
-
Zash
You're forgetting the stream header there