Modern XMPP project discussion - 2021-02-15

Probably because of varying support in clients and servers. If you make everyone use a single client and server implementation then it'll probably work fine, but that's kinda against the point of having an open soure ecosystem.

being more accessible on how to use xmpp for encrypted group chat could be usefull. A blogpost ot somrthing about compliance tester, clients and contacts you better add to your roster.

Another option that would increae UX a lot: being able to manually import OMEMO keys, in case fetching it from the server didn't worked out. (Some say, but that's to complicated: most systemli user propably know how to use PGP)

Nobody knows how to use PGP. Alone the differentiation between identity validation and trust is... 🤯

I speak about those that use the service of systemli. Many activists use and know how to use PGP.

purplebeetroot: regardless of the user group, nobody really knows it.

There was a very nice meeting ( XMPP Group Berlin ) about OX. I'm going to write some more information about OpenPGP in XMPP.

> purplebeetroot: regardless of the user group, nobody really knows it. You obviously don't know what you're talking about.

> OMEMO with a private group is definitely not where it should be IMO. never worked for me ever. someone always missing keys of someone else yeah that's a blocker for my circles as well :/

wfm

> I speak about those that use the service of systemli. Many activists use and know how to use PGP. I wouldn't be so sure

but I’m only using OMEMO with Snikket, so maybe the "broken clients" theory applies

Does Snikket add everybody in your roster already?

it does

for managed MUCs anyway

though that’s only a requirement if the OMEMO node is set to presence, right?

well yes and no. not saying I've got a magic solution, but I think Id prefer to be able to send anyway rather to be DoS'd by someone else adding a new person I don't have in my roster to the group

yes it's a usecase

private groups with co-optation / everybody can invite

my client could automatically send presence subscription but I still got to wait for the other user to accept, and in practice it doesn't always work smoothly

or just remove the access restriction from the OMEMO node

I'm not going of that but o thought it was already the case anyway. clients trying their best to set it public

so I'd say it's an intentional decision from C to not send when not having access to presence sub?

I'm not so fond of that*

(?? autocompletion)

right, it’s open

so yeah, maybe C being strange here, though it also makes sense because you cannot subscribe through MUC

so you can’t really know when keys get added or removed, which is not optimal

obvious terrible solution: broadcast a serial number for the OMEMO keys in <presence/>

less terrible solution: let MUC subscribe and forward headline notifications about OMEMO node updates from occupants

no, that’s terrible UX

I personally think it's best to be able to send a message not encrypted for everybody anyway. rather than be prevented from sending at all. ✏

for both the sender and the receiver side

don’t invite randos in your private groups

and getting DoS'd is fine? ✏

that's your usecase

itym "that’s your opinion man" ✏

no, that's your usecase.

we don't have the same

I need to be able to invite people not everybody knows

the solution for that is not to DoS *or* to send partially broken messages. the solution is to properly distribute the keys even in that scenario

(by letting the MUC forward notifications probably)

well I'm happy for you to come up with such a solution. in the meantime I'd like to be able to send messages plz

I'm fine to work with people on a proper(tm) solution, but as it stands C is unusable for this circle

good thing we have free choice of clients

because obviously there's many available clients on mobile with this level of usability

good thing you can fork C then

Just use yaxim and stop caring about OMEMO :P

..

Well, I wouldn't be opposed to merge a PR for OMEMO support into yaxim, but looks like there are no volunteers.

is that what the "modern" in modernxmpp stands for? only caring about the one and true usecase?

Somehow somebody ate my lunch by working some years full time on a NIH alternatve.

pep., I’m not speaking on behalf of modernxmpp in any way

I’m trying to find a solution to your problem (and as you don’t seem interested in working on the standards side of things, I can’t resort to anything but "fork it")

I'm not saying I'm not interested, I also do want a solution that's gonna be useful somewhat quickly. it's not breaking your usecase anyway. C "just" needs to remove that restriction while the protocol is getting fixed. I could even do it, but if there's no consensus there's no point

C removing that restriction would break my usecase

my usecase involves not sending broken messages, ever. ✏

right, I guess I have "being able to send messages at all" higher in my list..

well, my usecase does not involve inviting unknown people, so a missing key in 100% of the cases indicates a serious problem which needs to be fixed and shouldn’t go unnoticed

"it’s not as simple"

maybe the easiest hack could be a MUC setting? "hey I'm gonna invite random people"

Just to guide clients in their choice of behaviour

... this topic is not easy ... encryption is also related with trust. If you are going to encrypt messages with unknown people, how do you manage the trust of keys. I think before working on technical solution, functional analysis should be done.

Stefan: trust is delegated to everybody in the room in this case, there is no one authority that has the ultimate knowledge. Yes this can lead to trust being compromised but that's part of the game

the question is a valid one though

Yes, but this are different use cases and you may not needs OMEMO or OpenPGP for this game. 🤷

if you changed C to auto-fetch keys from occupants, the MUC server could trivially and completely compromise the encryption

step 1: provision a fake account on a domain the MUC server controls (e.g. its own domain) step 2: publish OMEMO keys there step 3: add that fake user as member and occupant, publishing its JID and a fake presence appropriately step 4: all users fetch keys and subsequently encrypt for the evil key from the MUC server

in this scenario, the requirement of a separate presence subscription reflects the trust in the new occupant

If only we had a mechanism to do trust transition.

on the plus side, we could have server-side MAM search in MUCs then ;D

attacker-side search!

:)

XMPP is just not suitable for proper E2EE

is anything?

m:n E2EE is tedious, that’s not specific to XMPP, is it?

a good design would be a decentralized DAG store of blobs and public keys, and the store would require new blobs/keys to be signed by one of the whitelisted key

MLS?

I still haven't read it.

it does something with a tree at least

which is a special case of a DAG

Wasn't that a tree of keys or something?

what if the user creating the room (who usually has all the contacts) sends keys to the others?

-ENOPROTO

yes, but any proper solution needs a standard there

there is no solving it without multiple client authors agreeing on the solution

> good thing you can fork C then Or you don't have the time for that, because your group has a focus on anti-colonialism, gender-euquality, climate justive...and then you're better off choosing something that works, rather something that could work if you build it yourselves

as the user with all contacts, they can already send encrypted, signed messages to the other clients, which can include the keys of all participants. maybe i'm missing something, but at the moment it seems to me like it could work

purplebeetroot, yes, then so be it ✏

without putting something of value to the recipient somewhere, you won’t get others to do the things you need.

always.

also holds for other things such as Signal or Matrix

I find this to be an hostile attitude. See, I'm privileged enough so that I don't need to care about colonialisms, but I care because I care about those to whom it matters. It is important that we do things for each other, at leat of we wish to improve society for the better. I also believe it is important in software development to investgate the different user groups and their needs, rather then focusing on just building for your own peer group.

purplebeetroot: what's your call to action? Have some random volunteers implement features on a client that the maintainer disagrees with?

purplebeetroot, I find this to be an hostile attitude. See, I’m a software developer in my free time only. I spend my time on what *I* need and want because nobody compensates me for anything else. Coming to me (or, really, a community mostly consisting of those individuals) and *demanding* things and claiming them to be hostile because of their reluctance to implement more code (= more maintenance work in the future) is not very nice. One of the few exceptions is Daniel (iNPUTmice), whom you could pay to implement the feature(s) you need.

The thing about e2ee is it doesn't have to be perfect all the way. Something something perfect and good

Pick your poison.

i don't see how this conversation is helpful. it's clearly a protocol issue when you cannot create a private chat with your contacts who are not yet all contacts of each other. it's a completely normal situation for private chats. so either the protocol explicitly doesn't support private chats, or it needs to work with those

pep., is that so? what is the point of imperfect e2ee? If we don’t need perfect e2ee, can we do away with "perfect" forward secrecy already, because that breaks other relevant UX.

raucao, there is not even a clear specification on what a "private group chat" is :)

yes there is. you're literally in the channel of a project describing it

there’s also no clear specification how OMEMO-encrypted groups even work.

yes, then that's a missing spec

raucao, modernxmpp does not describe protocol.

obviously

(for most part anyway)

you didn't say protocol. you said describe what a private group chat is

right

a private group chat is one that is not publicly listed, and where all participants except that it is encrypted. thus, it's not just an invite-only semi-public room, but a e2ee private room

s/except/expect

signal and whatsapp provide this by default

so whatever your personal reasons for not wanting it, you can hardly claim nobody does

if someone in this room says they do, then that's a user with a use case

but you don't really need to rely on random people here claiming it. i don't see how it's controversial that this is one of the main use cases in groups of friends and acquaintances

raucao, I am not arguing against encrypted group chats

or anything really. I’ve got a problem with people demanding that things should be implemented without being ready to put the work or money in.

then what are you arguing against? you're not constructively exploring how it can be solved, just telling people that they're wrong

raucao, I’ve made proposals

first, it works perfectly fine if everyone is in each other’s roster

> purplebeetroot, I find this to be an hostile attitude. See, I’m a software developer in my free time only. I spend my time on what *I* need and want because nobody compensates me for anything else. And? What's the point? Neither I or the groups I'm working with get compensation. Should I be protected from receive critism for whatever I do, as long it has no hostile intend, just because I don't get paid? This does not make any sense to me.

second, if we want to allow non-roster usecases, we are in deep trouble because of problems with key trust.

> first, it works perfectly fine if everyone is in each other’s roster which is a standard situation to not be the case

that's the entire point

why it doesn't work for so many people atm

and you can't solve it with snikket and such, when the group is not all on the same server with their accounts

that may work for family chats, but as soon as you invite friends from other servers, you're back at the same problem

I don’t think that allowing messages which are encrypted for only a subset of the group to pass is a good thing in the friends & family use case (or any use case really, but YMMV).

so the only way to solve this is to establish trust in the membership list in some way

and that is a really tricky issue

someone smarter than I will have to put the work into that, and that’s ok.

false dichotomy

raucao, how?

but apparently you know it all

I don’t see another way, but if I’m wrong I’d like to hear it

again, other protocols and messengers have solved this already. just because you don't see something doesn't mean it doesn't exist

(I know that how I word things -- especially when I’m in a hurry -- tends to indicate otherwise, but I want to be proven wrong)

you're not putting forward any detailed arguments, so it's difficult to prove anything

did they *solve* it, or did they *work around* it by making use of their advantages from a non-federated closed platform ?

if your argument is that signal hasn't solved this, then it's obviously invalid

raucao, okay, so my concrete problem with removing the requirement for roster subscription is this

nobody said anything lilke that

*if* we change clients to accept keys from all entities in a MUC, then it is trivial for a MUC to subvert communication completely

that's the false dichotomy

can we agree on that being true?

yes, hence my suggestion for accepting them from contacts only

who can rely keys of other contacts

hence being trustworthy

okay, so transitive trust

for example. and progressive perhaps

that’s essentially what Ge0rG said above, to which I said "MLS?" because I think that MLS *might* solve that in one way or another

i.e. when you then add someone it could switch from yellow lock to green lock or something, when it has double-checked the key

but it boils down to transitive trust, which we don’t quite have yet, and, it is equivalent to establishing trust in the MUC member list, which I also said is what we can do, but someone smarter than I needs to.

you don't need to trust the list, only the messages of the contact who invited you

so I still don’t quite see the false dichtomy there

you said either you trust the muc server or not

raucao, true

raucao, I don’t think I did

> did they *solve* it, or did they *work around* it by making use of their advantages from a non-federated closed platform ? explain how that changes the trust situation for e2ee and contact lists

also, matrix is federated, no?

or let me rephrase: I did not *intend* to do so. What I intended to say is: in the current state of the world, you need to trust the MUC server or use presence subscriptions (or manual key verification) to work around that. To go beyond that will require substantial protocol changes. ✏

> To go beyond that will require substantial protocol changes i don't see how sending some key messages around from the inviter is a "substantial protocol change". can't that be a simple *addition*, without changing the current protocol?

it is a substantial additional protocol which needs to be supported by all involved parties

substantial in the sense that it can’t work without and that it needs to be required

yes, but the worst case is that you fall back to the current situation

which we already have

which is always a problem in a federated ecosystem with diversity of clients.

right

fair enough

> or anything really. I’ve got a problem with people demanding that things should be implemented without being ready to put the work or money in. The point is: those with the needed skills will either solve it, or people will go with Matrix and Signal. Demand is: either it gets a high priority or I and many others loose interest. Neither do you know about money/resources that I've put into xmpp. So your problem seems rather linked to receiving criticsm in general.

purplebeetroot, as I said: I’m fine if you move to other solutions if your requirements cannot be matched by current xmpp implementations and you cannot or don’t want to put resources in to improve them

purplebeetroot, I’m sorry if I come across as hostile because of that

that’s not what I want really

What is needed to improve it?

(Ok)

purplebeetroot, I’m not sure if https://xmpp.org/extensions/xep-0434.html (also cc @ raucao) is a way to establish that transitive trust in MUC context

so at the very least we’d need some explorative implementations around that and see which bits are missing and how to securely distribute the trust and distrust messages

oh, nice

that could work already

i mean just as the messages for sending around the keys to contacts

wouldn't that also then make the MUC member list trustworthy, when the JID's are equivalent to what the inviter sent out?

raucao, exactly

(hence I always simplified my argument to "establishing trust in the member list", because in this context, it is pretty much implied) ✏

(not equivalent, because trust messages are stronger than that by also establishing a list of keys which are OK)

> Ge0rG escribió: > Just use yaxim and stop caring about OMEMO :P I was waiting for this comment 😊

If you want MLS to solve all problems then you should join the work group and make sure it actually does in a way compatible with XMPP, otherwise it's likely only going to work with silos and matrix, as those seem to be the ones involved

There is only so many yaks a man can shave.

Zash, what can we do about the IETF being a big scary venue some might not feel adequate to join?

*if* that is why the OMEMO folks don’t integrate there

Dunno. That seems to be the problem, doesn't it? OMEMO didn't cone from any standards related community either and the deployed version is still not the cleaned up standardized version afaik.

NIH?

how do i find out the max stanza size in modern XMPP?

I don’t think there’s a way

(except the hard way)

(i.e. getting your stream killed when you exceed it)

Roll a d1T and try it

so it's an expected behavior for an user to be kicked from the server because one happened to upload too big of an avatar or smth? T_T

Yes

Known bounds I'm aware of: ejabberd: 256k Prosody: 10M ✏

for c2s. ejabberd has 512k for s2s

thanks

For very big avatars it would have been sensible to use http upload, but people also wanted limited retention, so that won't work now.

So accounting for base64 and padding you're limited to around 192 KiB for avatar

raucao, yes it's a protocol issue, i'm interested to have a chat on this topic of private E2EE if you'd like that :)

jonas’, new keypairs advertised by the MUC should be signed by existiing members of the group with their key, so as long as one member of the MUC has direct communication (roster etc) with the invitee, they can be vetted for in a public manner, similar to a WoT but with only one hop

ah yes that sounds like trust message, though i haven't read the XEP yet

anyway in some cases the MUC server should keep an append-only log of those vettings, but in some other cases only the latest state should be kept.. it's two different threat models (obfuscating the social graph vs audit trail)

“jonas’> pep., is that so? what is the point of imperfect e2ee? If we don’t need perfect e2ee, can we do away with "perfect" forward secrecy already, because that breaks other relevant UX.” I won't pick up the PFS fight. Re "what is the point of imperfect e2ee", not sure if serious.

what's the point of buggy TLS implementations (hint: they all are?)

"jonas’> or anything really. I’ve got a problem with people demanding that things should be implemented without being ready to put the work or money in." also this is not what I'm doing here.

"jonas’> *if* we change clients to accept keys from all entities in a MUC, then it is trivial for a MUC to subvert communication completely" this doesn't matter for my usecase

I mean it doesn't, until it does, but I'd rather trust a MUC than not being able to send a message

Or we can try to implement multicast, but then it's a whole different threat model

It would be nice to have the role of the server clarified in the threat model.

The server is your friend, until it's not.

koans-of-modern-xmpp.xml

Zash, i'm interested in clarifying different threat models for MUC, following some discussions where i learnt mod_muc_occupant_id completely "disables" pseudonymity for MUCs by letting other MUC members associate different nicks to a single identity (which is a feature to some client devs apparently, but a WTF security-side)

is there a MUC or working group working on threat models for Jabber/XMPP ecosystem?