XSF Discussion - 2024-08-09

conversations is not considered as a small project i hope ?

Conversations has existed before the NGI money came in and will continue to exist after. We have a business model that (sort of) works. NGI is an important initiative - it has also helped us to work on Ltt.rs - but Conversations doesn't rely on it.

ok

Daniel , somebody wants to kill you because you haven't not release C3 yet. Do you have any comment on this ?

and I am the person who's behind this "totally serious" death threat

😎

Trung, most of the promises of c3 have been quietly making their way to c2

oooo

>> I've said before, terminating the "E2EE" at the server would make a lot of sense for a lot of cases. Means putting OMEMO into the server, of course, which is challenging on a number of fronts. > How is that any different from TLS? Well, I'm assuming a threat model where that level is acceptable at your end, so if you run your own server or have mutual trust with whoever does. But it would differ with just TLS at the other end.

> does anyone know https://wiki.xmpp.org/web/GideonW_Application_2024 ? gonna be hard to vote for him given that info... Alex should I reach out? ↺

I think that doesn't conform to the requirements laid out in the most boring XEP I ever wrote. Needs affiliations.

moparisthebest: I have technical opinion, but "wording" is good so far. I also share your opinion in general feel free to add it to the newsletter

h

This person attempted to retract a previous message, but it's unsupported by your client.

> Alex should I reach out? I noticed this applications some days ago. Was my plan to reach out when its not getting updated. I will do this today. In the current form I cannot accept it anyway. Does anyone know the applicant? ↺

singpolyma mentioned knowing them and that they just might have not finished updating their application

yup, this is my assumption as welll and why I wait usually before I reach out

Anyway, I just reached out, because I am traveling next week and will not have lots of time before the end of the deadline next week

Thank you and safe travels 🙂

Alex: Thank you Alex!

Yes I asked that applicant and they intend to finish it but were traveling, should happen soon

If a server has dialback enabled, and gets a cert from a remote server, when should or shouldn't it try dialback?

When the cert fails to verify at least

I guess I'm asking for 2 seperate answers: 1. What do server implementations in the wild do now? 2. What should they do? :)

> When the cert fails to verify at least Just in any way? That seems wrong no? ↺

Might be nice to do it always since I'd trust dialback more than a cert

I tend to think nowadays with LE the default behavior should be to only dialback on no cert at all...

And so, only when TLS isn't required

Are you asking about dialback without dialback?

Snikket disables dialback entirely due to agreeing with you

I think dialback should be disabled by default across the whole public federation for sure, and it actually seems to work fine that way for some years, but that's a different discussion :)

Dialback the protocol is bad and confusing. Dialback the abstract verification method is nice for some cases, e.g. where you can't get a cert from Let's Encrypt or somesuch.

Context is from xmpp:operators@muc.xmpp.org?join where joinjabber has had an expired cert for days but didn't notice because a ton of servers connected anyway... Wondering why

Huh, I had forgotten about https://hg.prosody.im/trunk/rev/a8367f169740 which went into Prosody 0.12.0.

Well most were probably already connected

Yeah I don't think anyone closes connections when the certs expire.

Unless you count all those servers that agressively close idle connections.

Right, but more context is this was right after a server move, so it wasn't that...

> Huh, I had forgotten about https://hg.prosody.im/trunk/rev/a8367f169740 which went into Prosody 0.12.0. This seems like a good default imho ↺

Configurations based on the previous defaults may not have been updated by everyone tho.

And that doesn't disable Dialback (the protocol), only Dialback (as a method of establishing trusted identity).

Metre always handles the XEP-0220 wire protocol, but by default only does PKIS for authentication.

PKIX, rather. :-)

So, in particular, if a remote server it's connecting to doesn't offer SASL EXTERNAL, it'll verify the cert anyway, and request dialback only if it passes.

Sounds like what Prosody does with `s2s_secure_auth = true`

And if a server connects to it, Metre verifies the cert and offers both SASL EXTERNAL and dialback - and if the server sends a <db:result/> it'll get a <db:result type='valid'/> straight back.

Metre being Metre, you can reverse all this, so it'll ignore the TLS cert and only use dialback if you really want.

As for expiry... The principle problem with an expired cert is that one can no longer discover if it's been revoked. I suppose arguably, if you're not checking for revocation status anyway, then why worry about it being expired?

And FWIW, 178 db:results received in the past 24 hours, 174 db:verify.

Got numbers on how many unique hosts do it? Hard to tell the difference between 170 hosts doing dialback once and one host doing dialback 170 times

equally tricky numbers, current s2s connections to here ({muc.}xmpp.org): 1034 Not used 7 Completed

> Context is from xmpp:operators@muc.xmpp.org?join where joinjabber has had an expired cert for days but didn't notice because a ton of servers connected anyway... Wondering why ah wasnt part of that group so that is where it was reported

what happened actually there was pretty interesting. certbot changed the directories for some reason

either way it will be fixed tomorrow as a heads up :D

Right but I'm curious why so many servers connected back anyway when really they shouldn't have...

moparisthebest, set up a server with a self-signed cert but otherwise valid DNS etc so Dialback will work, try connecting to some servers and see if they Dialback and authorize the connection?

I could do this with badxmpp.eu, but it's friday and I'm lazy

Yea, but that wouldn't tell me if any servers handle "untrusted cert" differently than "would be trusted but expired" for example, maybe they don't though

get a real cert, wait until it expires, don't renew it

ooh or see if I have an expired one in my backups...

Daniel, > There are certificates that are valid for the XMPP domain example.com but not for the regular (HTTP) server on example.com. Where are such certificates? Not issued by any regular CAs since they're forbidden by the CA/Browser Forum

🤷‍♂️

Private deployments presumably

And how do we infiltrate the CA/Browser Forum to fix that? :/

I think there's that srvTarget or similar? But yes not on the public federated network

I'd rather convince CA folks to issue .onion certs first...

> I'd rather convince CA folks to issue .onion certs first... This is coming soon as I understand ↺

> I think there's that srvTarget or similar? But yes not on the public federated network There are two mechanisms. One 'generic' for srv records and one specific to xmpp

> This is coming soon as I understand Or did I dream that? I was sure I saw movement somewhere :| ↺

>> I'd rather convince CA folks to issue .onion certs first... > This is coming soon as I understand ooh exciting, I know they've talked about it for forever but I hadn't kept up to date ↺

https://mailarchive.ietf.org/arch/msg/acme/25r41sV0_l-Fc1a-_COJn4XKxts/ constitutes some kind of movement, maybe I dreamed the rest

re SRV-ID, https://github.com/letsencrypt/boulder/issues/1309 is still depressing

Oh but https://github.com/cabforum/servercert/issues/268#issuecomment-2102926797 is more encouraging

> Got numbers on how many unique hosts do it? Hard to tell the difference between 170 hosts doing dialback once and one host doing dialback 170 times True... And this isn't really telling us muhc about whether they're reliant on it for authentication of course. I'll add the telemetry for domains, though; I'm currently missing quite a bit.

I've had dialback disabled for years I think at this point and haven't seen a server I can't connect to or vice versa...

c.im custom domain customer but probably not much else

Do they still do c2s-only POSH?

Or rather, do they do s2s POSH yet? ✏

I believe posh is c2s only. I'm not sure any servers support it for s2s anyway, which is probably good ✏

There's a module for Prosody :)

Of course there is 🙂

I would, of course, rather see more DANE

posh supports s2s and xmpp-proxy supports it on both c2s and s2s, so maybe that's why I haven't noticed anything not working lol