XMPP Service Operators - 2024-05-07

> Posting my manifesto here one more time: https://codeberg.org/divested/safeguarding-xmpp-2025 > Any feedback would be appreciated. > It is a serious proposal to push the ecosystem forward despite the jokes here about it in the past. Tavi: https://github.com/curl/curl/pull/13544 seems to support you ↺

Some v1.2 cyphers remain secure enough... dropping v1.2 can hurt users...

Microsoft is slow to adopt TLS v1.3, they have now on new servers but older ones still run 1.2

Its a good recommendation to support v1.3 if you can, but kicking out anyone who doesn't is wrong ✏

Although maybe it should be specified what TLSv1.2 cyphers remain unbroken, and which are broken, and to ensure to configure your XMPP server to reject the weaker cyphers

i mean prosody at least already works like that

debian, too, has quite strict openssl defaults these days

hrm

> Certificate fingerprints MUST be verified if TLSA records are available Some registrars make you pay for this as "additional security"

so they are technically available, but not finantially available

> Some form of E2EE MUST be supported Some clients still do not have OMEMO implementations, Spark is one. Until all clients listed on xmpp.org have some E2EE implemented, it might be best to downgrade MUST --> SHOULD

Polarian, excellent reason to move your DNS elsewhere if they extort you to deploy specific record types. ✏

also MUST seems overused, from what I read from the RFCs, MUST is used when not following it would cause severe damage or insecurity... not using E2EE won't instantly pwn you

> Polarian, excellent reason to move your DNS elsewhere if they extort you to deploy specific record types. I am working on it 🙂 ↺

> Some v1.2 cyphers remain secure enough... dropping v1.2 can hurt users... The protocol improvements are missing in 1.2; there are not only the cryptographic primitives but the way they are used TLS 1.3 is already 4.5 years old; one could wait for Browser vendors to force the new version or do this as XMPP community within this ecosystem; the main reason for missing 1.3 that I see is missing maintenance

don't tell anyone about the fact that I have TLS 1.1 enabled on one of my services even. ✏

but why

ankarl, android 4.4

jonas’, I am not saying do not push for TLSv1.3 adoption, but TLSv1.2 should still be supported, provided they are using the stronger cyphers, and not the weaker cyphers

Polarian, which is exactly what it says: support tls1.3, strong tls1.2, and optionally consider disabling 1.2

> Polarian, which is exactly what it says: support tls1.3, strong tls1.2, and optionally consider disabling 1.2 if public servers disable 1.2 then they can't be peered with ↺

thats a horrific idea

of the hundred+ servers mine connects to, only 2 don't support tls1.3

Polarian, I agree with you.

> of the hundred+ servers mine connects to, only 2 don't support tls1.3 and what if them 2 wanted support? ↺

search.jabber.network knows at least a dozen servers which connect via TLS 1.2 only, among them is conference.jabber.org

also I know you hate windows Tavi , but you got to bare in mind windows lacks behind in adoption...

who here is running their server on windows?

Probably nobody, but we aren't including the corporate entities or others which use the server software which you want to force them to drop TLSv1.2 support...?

I never said to drop 1.2

well then i am getting confused.

Also with E2EE TLSv1.2 would be reinforced, even if it is broken only the stanzas can be seen, not the payload

payload being the message

Dino can't seem to pick up a snikket OMEMO key... anyone got any ideas?

Polarian: restart both clients

tried that

conversations can pick up the key, dino will not

>> of the hundred+ servers mine connects to, only 2 don't support tls1.3 > and what if them 2 wanted support? It's like the Browser vendors dropping support - if the majority does it then they are forced to update their server software and configuration

which is why I'm proposing it now and it is for 2025

TLS 1.3 is required for the future use of quantum resistant key agreement

> TLS 1.3 is required for the future use of quantum resistant key agreement haha saw this one coming ↺

you haven't mentioned kyber in it

I expected "A server MUST provide kyber support"

1.3 is also required for ECH, which mopar is already working towards for xmpp

> It's like the Browser vendors I think our environment is quite different from the web universe. The latter is driven by two-and-a-half global players on the client side. Those set the de-facto standards and can move the ecosystem with same pace. There's tons of niche use cases using HTTP that are often broken by that pace, but Google won't care less. Our ecosystem is less centralized, plus the man power driving it is in no way comparable to that universe.

> then they are forced to update their server software and configuration In practice, dropping support for old mechanisms forces some but not all setups to update. The remaining setups will just break (adding to the general 'XMPP is broken' perception) and some of their users will just give up. So I think the question whether support for $x should be dropped should be driven by the question whether breaking those remaining setups is indeed preferable due to the (security) cost of supporting $x (no quantum resistance) being considered too high.

If quantum resistance is such a big deal then surely it should be incorporated into OMEMO

worry about TLS at a later date

seen as there is no TLS standard yet for quantum resistance (that I know of) ✏

again my proposal is simply mandating that TLS 1.3 be supported by servers to ensure clients aren't held back it still allows for use of 1.2 with strong ciphers to ensure legacy compatibility

Polarian, https://datatracker.ietf.org/doc/draft-tls-westerbaan-xyber768d00/

Chrome, Edge and others are shipping it Firefox will be shipping it soon too

> Polarian, https://datatracker.ietf.org/doc/draft-tls-westerbaan-xyber768d00/ draft != standard ↺

> Chrome, Edge and others are shipping it > Firefox will be shipping it soon too good for them ↺

all 3 of them have huge dev teams

> again my proposal is simply mandating that TLS 1.3 be supported by servers to ensure clients aren't held back > it still allows for use of 1.2 with strong ciphers to ensure legacy compatibility "TLS 1.2 SHOULD be disabled if unlikely to impact users" ↺

I think you need to review RFC2119

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

What you are saying and what your draft says are two completely different things

Your definition in this channel is more a MAY than a SHOULD

The entire point of a manifesto like this is to drive the ecosystem forward, convince the 2% of servers that don't support TLS 1.3 to upgrade We don't need a manifesto to continue the status quo of "hey maybe upgrade one day if you want"

XMPP is meant to be an extensible protocol to fit all needs

carpet bombing it with extreme restrictions is not the way to do it

Security is one aspect of XMPP... and yes security matters, but you can't wall off the garden simply because you desire it.

Restrictions? Lol. I have no idea how one could misconstrue a list of best practices as restrictions

Like I said, nothing wrong with SHOULD use TLSv1.3, that is a good recommendation... but telling people to drop TLSv1.2 is a bad bad idea.

Telling people to support 1.3 and plan to drop 1.2 in a year*

> Telling people to support 1.3 and plan to drop 1.2 in a year* half a year ↺

its May...

See also https://github.com/curl/curl/pull/13544

moparisthebest, I guess the target audience of such manifestos is rather the 98%, and it's about suggestion them to drop interop with the 2%.

You can't justify extremism by saying "oh look another project is doing it"

XMPP is a much smaller community, you are looking at big IM and big platforms and saying "we should do that"

Holger: there are probably still servers that don't support TLS at all, no one misses them

TLSv1.3 should be the recommendation

maybe in 3-4 years after, or if TLSv1.2 strong cyphers are broken, THEN ban them from use

moparisthebest, I'm all for doing that if it seems desirable from a security point of view. I'm just saying it should only be done if we *actually* prefer breaking communication over supporting e.g. TLSv1.2.

Why 8 years instead of 6 Polarian ?

TLSv1.2 strong cyphers are still considered secure enough for business use...

> Why 8 years instead of 6 Polarian ? to give time... ↺

at least make a deprecation notice first

moparisthebest, I've just seen people pressing shiny security knobs and then being surprised that things broke stuff way too often.

How old of TLS libraries are people exposing to the internet? Yikes

to me XMPP is about suiting everyone

Polarian: this is meant to be the deprecation notice

oh nice a quick warning, "heads up servers, in 6 months you will be de-peered if you don't use TLSv1.3"

hell, one post in a XMPP channel isn't even a good warning

AT LEAST post it to the mailing list

No one said dates can't move around, it's an early draft he's asking for feedback for

It's not done or ready for that...

https://codeberg.org/divested/safeguarding-xmpp-2025#system-security and https://codeberg.org/divested/safeguarding-xmpp-2025#system-updates are not XMPP related

https://codeberg.org/divested/safeguarding-xmpp-2025#system-firewall relying on third party block lists for IP addresses doesn't sound like a good idea either...

why not? the server runs somewhere so having guidelines for secure system seems good

> why not? the server runs somewhere so having guidelines for secure system seems good because where do you draw the line ↺

on the software where else?

if you self host a server should you start being told to buy CCTV or how to effectively shred disks

> on the software where else? memory encryption is more of a hardware thing ↺

cctv says nothing about the security of the server so sounds like a strawman

> cctv says nothing about the security of the server so sounds like a strawman it was an example... ↺

my point was... people have different situations

> > on the software where else? > memory encryption is more of a hardware thing maybe. but the guide should aim to be accessible

saying to be buy special hardware is out of scope

Don't forget stuff like Pidgin.. Adium and the rest in your equation...

MSavoritias (fae,ve), its about hardening/securing XMPP

not the entire systme

yes you could argue that the system can make XMPP insecure, but then you could argue the datacentre you pick, or if you self host also damage this too

I had someone for lightwitch.org a month ago telling me he still used Windows 7

so dropping TLS1.2 will for sure make people very unhappy

> I had someone for lightwitch.org a month ago telling me he still used Windows 7 Windows 7 has had support dropped for years, its likely security broken anyways ↺

Now I know 99% of people here are likely Linux sysadmins, but: > Daemons SHOULD be confined via a MAC such as SELinux Is controversial

Same with old Androids, at some point it becomes irresponsible to enable these people to keep such broken systems online

> Now I know 99% of people here are likely Linux sysadmins, but: > > > Daemons SHOULD be confined via a MAC such as SELinux > Is controversial why?

Without having the entire argument with Tavi again... some operating system(s) (not naming names) do not support MAC and never will...

I don't think "basic sandboxing is a good idea" is controversial in any way...

making it a requirement thus would make it non-conforming with the security standards set

> I don't think "basic sandboxing is a good idea" is controversial in any way... MAC itself is controversial, sandboxing is not ↺

And examples for the OS used 99.9% of the time also seem called for

saying "The server SHOULD utilise sandboxing" fine ✏

every platform has a way of sandboxing

Right and it says "such as" so perfect

no

because it specifies MAC

> Distinct public facing services SHOULD be isolated to their own (virtual) machine Ambiguous, What counts as distinct public facing services...?

The reverse proxy counts?

also depending on what counts, it could have significant performance implications, and also significant cost, virtualisation isn't cost-free security

low memory servers wouldn't be able to conform

> Secure Boot SHOULD be used if supported by host and operating system HIGHLY controversial

Heads is objectively better, but doesn't have the platform support

microsoft certificates exist, which kinda nullify the entire point of trusted boot, and secondly, trying to enroll your own to replace them can brick hardware...

come to think about it, there is no mention of FDE?

oh wait, "disks should be encrypted" sorry

> On disk swap MUST NOT be used Reason for this? encrypted swap should be secure no?

I haven't read the proposal yet. Where's the preferred place for feedback? Polarian's made a bunch of points in here (to which I agree or disagree with varying amounts), but with multiple pieces of feedback, some of them will get lost to the scroll. If I go through it and have more than a couple, MUC might be the wrong place for discussion.

Fishbowler: codeberg seems like the least likely place for comments to be forgotten

> Fishbowler: codeberg seems like the least likely place for comments to be forgotten also a good way to go on the record... and I do not have the confidence to do that 🙂 ↺

~plus I don't have a codeberg account~

Possibility of moving this to the mailing list?

I feel that this is more something which should be done in a dedicated thread, instead of keep bumping it in the channel... and I don't think its fair to make people create codeberg accounts to discuss it... anyone appose moving it to ML?

Polarian: it lists 4 places to provide feedback You yourself said the mailing list was dead

Also I want to iterate again it doesn't drop 1.2, I don't know why people keep saying it does

And 1.3 is seven years old already

> android 4.4 jonas’: 4.4.4 supports 1.2

then it's maybe Conversations Legacy at fault? I know that I had to do *something*

> it doesn't drop 1.2 It says "TLS 1.2 SHOULD be disabled if unlikely to impact users", not sure how operators of open servers are supposed to judge on that "if" condition.

> Polarian: it lists 4 places to provide feedback > You yourself said the mailing list was dead what? when? ↺

I never said the mailing list was dead, the mailing list is new \o/

(ish)

> Also I want to iterate again it doesn't drop 1.2, I don't know why people keep saying it does then replace the SHOULD with MAY... ↺

and even then MAY still would cause issues

Holger: one could just check their c2s and s2s for a few weeks to see if they are utilized or not

> Polarian: it lists 4 places to provide feedback > You yourself said the mailing list was dead issues on 3 different git platforms, or pollute the entire XMPP service operators channel... only one discussion can happen at one time here... and this discussion is likely to take weeks ↺

so I stand by the suggestion of moving it to the mailing list

> > it doesn't drop 1.2 > > It says "TLS 1.2 SHOULD be disabled if unlikely to impact users", not sure how operators of open servers are supposed to judge on that "if" condition. +1 ✏ ↺

although come to think about it, its a logical fallacy, its AND False... because it will always impact users, so it can never be true... 🙂 ✏

sorry its not AND, it would be an implication 🙂

> then replace the SHOULD with MAY... > > and even then MAY still would cause issues "MUST consider"? 😁