Modern XMPP project discussion - 2025-01-27

>> Signal is done pretty well, but its deliberate with it's leaks so much it pisses me off. > my point isn't that Signal's bad (though I don't like it), if someone was saying the same things but with XMPP being the only good platform I'd also consider him as much of an idiot as Soatok 🤔 ↺

> this isn't a criticism of Signal. The problem with Soatok's stance is that they are incapable of undestanding that not everything fits into the narrow use-case that Signal fits for. tbh in my experience this is in general with security people at least in matrix/xmpp ↺

the amount of time i had to argue that yes windows is more secure than linux but it still shouldn't be used is more than it should be.

> The clown even deleted a very reasonable response from the author of Omemo from the comments of his blog. Anyone still got a copy of that? ↺

> the amount of time i had to argue that yes windows is more secure than linux but it still shouldn't be used is more than it should be. Windows doesn't have Wayland though, so applications can keylog and fake input into each other ↺

I've written some Windows malware myself and you can do some pretty nasty things

One of my malware also worked on Wine

whether it is not is not the point. the point was what Kris said. people like blogger above have already a predefined standard that they measure things in.

But not on Wayland

and xmpp is never gonna be that because the point of XMPP/Omemo is something else. but these people miss that point and think they are "objective"

and in my experience that is a lot of security people i have interacted in martrix/xmpp that are like this

> Yes, but MLS for xmpp is a work in progress Where is this progress? I'm mildly interested in this ↺

there has been no news in months afaik

I don't know why we need MLS if we already have OMEMO. Will OMEMO be ported to MLS or is it going to be a whole new spec?

OMEMO has its shortcomings like no append-only world-wide writable log like WhatsApp is planning to do

But I'm not sure how that will work

It will be very interesting if that even works and if it fixes the very easy MITM "exploit" that OMEMO has

> It will be very interesting if that even works and if it fixes the very easy MITM "exploit" that OMEMO has Can you elaborate on that? ↺

Basically, I hypothesize that any server can fake OMEMO keys, as most users will hit accept anyways

It falls outside the threat model of the OMEMO spec but it is a real issue

Only 1% of OMEMO users (made-up statistics from my personal experience) will verify keys, and only a few of those would do it outside of XMPP ✏

Most clients have blind OMEMO trust turned on too

reasons being really Squeaky Latex Folf 1. We have no cryptographer in XMPP willing to improve Omemo for years now 2. MLS is a standard and good designed 3. Omemo has problems to scale in large groups and also serious usability issues that never got fixed

the scale problem could be fixed if we had a cryptographer. we do not. MLS does

the usability problems i hope we dont mess up MLS that much personally. but parts of it should be easier at least to implement

> Basically, I hypothesize that any server can fake OMEMO keys, as most users will hit accept anyways that is true for any e2ee currently that verifies keys automagically. (including signal) ↺

Yeah but I heard WhatsApp was going to experiment with a world-wide append-only log where users upload their keys too and revoke their old keys

it can be improved tho i think. with stuff like ATM

ATM?

https://xmpp.org/extensions/xep-0450.html

> Yeah but I heard WhatsApp was going to experiment with a world-wide append-only log where users upload their keys too and revoke their old keys doesnt matter really. since whatsapp is closed source and owns the server. ↺

they can promise anything but they cant prove it. signal can prove it on the other hand

Is there a draft for MLS on XMPP?

if there is i would like to see it too :)

>> The clown even deleted a very reasonable response from the author of Omemo from the comments of his blog. > Anyone still got a copy of that? Squeaky Latex Folf: https://www.moparisthebest.com/tim-henkes-omemo-response.txt via https://www.moparisthebest.com/against-silos-signal/ ✏ ↺

> they can promise anything but they cant prove it. signal can prove it on the other hand MSavoritias (fae,ve): Agreed that a proprietary server can't prove that it's doing what it claims to - but doesn't the same apply for a centralized service? Or is there some way Signal can prove they're running their free code and not something else? ↺

>> they can promise anything but they cant prove it. signal can prove it on the other hand > MSavoritias (fae,ve): Agreed that a proprietary server can't prove that it's doing what it claims to - but doesn't the same apply for a centralized service? Or is there some way Signal can prove they're running their free code and not something else? The majority of tooling that we expect can be verified on the client. ↺

> MSavoritias (fae,ve): Agreed that a proprietary server can't prove that it's doing what it claims to - but doesn't the same apply for a centralized service? Or is there some way Signal can prove they're running their free code and not something else? i agree. but its more controversial to make that claim because - signal does have their server code in github. (updated every how many years) - signal's entire point is not to trust the server - there is a project by the linux foundation (i think) that allows you to check that the server runs what they say they run ↺

nobody uses the last one afaik

MSavoritias (fae,ve): curious, what's that called?

hmm let me see if i can dig it up

so i found some things. i think the project was renamed or something since i saw it. DISCLAIMER: I DO NOT agree with doing any of this and think it is a technical solution to a social problem :) So basically what i saw is called "confidential computing" or "remote server attestation". What happens is that you boot and verify a server remotely inside things* that it actually runs what it says it does. Everything is verified through TPM and such. Projects are: https://keylime.readthedocs.io/en/latest/ > Keylime is a TPM-based highly scalable remote boot attestation and runtime integrity measurement solution. Keylime enables cloud users to monitor remote nodes using a hardware based cryptographic root of trust. https://confidentialcomputing.io/2024/10/02/what-is-remote-attestation-enhancing-data-governance-with-confidential-computing/ > Imagine you’re working for a large healthcare provider. You have patient data that needs to be processed in the cloud, but you also want to make sure that this data isn’t accessed or tampered with by anyone, including the cloud provider itself. How can you trust that the cloud server is secure before sending sensitive information to it? That’s where remote attestation comes in. It’s like a virtual “security checkpoint” that ensures the environment where your data will be processed is trustworthy.

confidential computing is part of Linux Foundation btw

> - signal's entire point is not to trust the server Signal's entire point is to pretend you should trust them by agitating all kinds of marketing slogans while they put themselves at the front and center of everything, that is reason-enough for heightened suspicion. In my book they are no better than Whatsapp: your messages are mathematically secured, but they are not private: the man in the middle has a quite good idea of who you are and what you do. And Re: confidential computing, or whatever they call it today: this is more security by obscurity. Last I checked, both Intel and AMD implementations of secure enclaves were flawed, which is besides the point, really: you must still trust that Signal is running in there what they advertise (they won't let you push and execute your own code "as found on github" for obvious reasons).

rom1dep: very well put

I hope that in the future trusted computing just collapses, or exploits become more reliable and unfixable, so we can truly own our hardware again

Power9 doesn't have this 😇

rom1dep, does that also apply to xmpp ? mitm is always a problem

signal does not have the concept of federation which means self hosting becomes impossible. but in xmpp you can always self host and the trust issue become less valid ✏

Precisely, XMPP lets you choose whom to trust if not yourself (and makes self-hosting pretty easy, which is awesome)

But XMPP identities are not entirely transferable. JID changes if you change server.

> But XMPP identities are not entirely transferable. JID changes if you change server. Which identities are entirely transferable then?

hubzilla has that https://hubzilla.org/help/developer/zot_protocol also activitypub is working on the same thing and there is also DIDs

https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse/2101/72

Could there possibly be something like SSL, you know, an authoritative server or a built-in certificate, to help verify fingerprints? Just a thought—maybe it’s a bit far-fetched!

Can blockchain do it?

Static/unique IDs bound to one's person have their pros and cons too, btw.

What if you want to change your ID.

saf: we do something similar for other tech. We did use a blockchain to write to which does work but becomes prohibitively expensive, instead we have a custom usenet-esque server which essentially is a federation of users who have interest in keeping the keys.

We had different keys so couldn't use the regular keyserv was easier to remake it than ask them to expand the feature sets lol

On a completely different topic. IIRC, Nintendo is using XMPP for the presence and messages on the Switch. As it's heavily rumoured Switch 2 would have (group and even AV) chat capabilities, would be cool if it was using XMPP too.

Even cooler, if it were possible to connect with a different client too (extremely unlikely though)

The ejabberd people likely know

…and probably not at liberty to say much, I’d imagine 🙂

This was an interesting read though https://www.process-one.net/blog/ejabberd-nintendo-switch-npns/

> …and probably not at liberty to say much, I’d imagine 🙂 👍 ↺

> hubzilla has that https://hubzilla.org/help/developer/zot_protocol > also activitypub is working on the same thing and there is also DIDs How does it work? Through a DNS record like on ATProtocol? I'm thinking, how would one implement this on XMPP? Perhaps an XMPP server can query the DNS zone for a JID's hostname, and check if there's a record in there that specifies some kind of XMPP authoritative server, and then connect to that server instead. ↺

Nomadic identity in hubzilla is basically a cryptographic key that identifies an account and a fancy replication sheme to keep multiple accounts in sync. No dns involved directly. ✏

Hmm. I don't know how that works.

you just sign messages on the client to prove you're the same person

on the client *side*, not manually usually

its pretty simple in theory to add it to xmpp too. you just decouple the jid from the DNS. so the dns jid bob@example.com is just an alias/external representation of a key (DIDs can be used here)

and you sign messages with that key as raucao said

simple (tm) of course

simple ≠ easy

agreed

raucao: that video you posted was really good

My point of the issues is actually complimentary after watching it I would think

The fundamental issue that I have seen is access to participants keys, using a mechanism to cross sign and cache keys on a per server basis would assure that a counter participant can verify its the correct key and the server can push the pubkey for a user without compromising their JID or if they are offline for key exchange

PKARR with lots of caching has a chance of working IMO

https://github.com/pubky/pkarr

publishes keys to mainline DHT

but xmpp has public PEP nodes for example

That seems hella similar to what we made

Let me share a somewhat unrelated technical observation: I once came across an internal system where the designer surprisingly reused an existing CA certificate from the server to implement encryption. They completely ignored the Basic Constraints field and forcibly issued sub-certificates. These sub-certificates were deployed on user devices, and mutual authentication relied solely on verifying whether the peer's certificate was signed by the server's CA certificate. While this approach might work within an internal environment, it clearly violates standard TLS validation workflows. Personally, I don’t see any real advantage to this method, even for internal use cases. Beats me what they were thinking.

What does DID mean?

Distributed Identity - its a sectionally revealabe protocol made by Microsoft identity team Squeaky Latex Folf

Its pretty cool if I remember right

Microsoft invented it? For what?

The purpose is to be able to verify information without revealing the information itself

For instance if you were to order a bottle of whisky online, you could use a did to verify you are over 18 but not what age you are or where you were born

Its about revealing the absolutely minimally required information

https://www.w3.org/TR/did-1.0/ > The Decentralized Identifiers (DIDs) defined in this specification are a new type of globally unique identifier. They are designed to enable individuals and organizations to generate their own identifiers using systems they trust. These new identifiers enable entities to prove control over them by authenticating using cryptographic proofs such as digital signatures.