jdev - 2023-07-03

Hello! How secure OMEMO is? I want to write a chat bot in python with slixmpp and slixmpp-omemo (and also package those for GNU Guix). Maybe there is a different implementation that is more secure and modern, even for a different language?

It is considered secure. It is basically the signal protocol.

Thanks, python-omemo has been updated to v1.0.2 but slixmpp-omemo uses v0.*.*. Hope some one can help devs to update it

not every project uses the same versioning scheme

OMEMO doesn't protect metadata unfortunately

VesselWave: python-omemo implements new version (OMEMO:2) which allow to encrypt basically anything, while the legacy version only encrypt body of message. It is still compatible with legacy version which is the most used in the wild.

I just wasn't sure if I should use this version and package it to Guix, if it's insecure (it's not) and maybe new one will be available soon. Now I see that everything is alright. I will finish packaging and maybe will submit it to Guix. Thank you

It would be cool if the from attribute could be encrypted in some way as a protection against metadata gathering

you cant. its a fundamental property of federating systems. unless you mean tls. then yes it is

we can secure it more by doing stuff like dnssec and other stuff. but not encrypt completely

it would be possible to hide the @to localpart+resource from the sending server, and the @from localpart+resource from the receiving server (with heavy protocol modifications of course)

while still being federated? sounds interesting.

provided everybody adopts the modifications of course

msavoritias, the localpart and resorouce are only required for routing by the domain on which it's hosted ✏

otherwise the servers only need the domain

(and the sender's domain needs to be available in cleartext on the receiver's server to avoid domain spoofing)

so only the domain has to be in the clear. got it. will make a note of it thanks 😀

but if you actually want to obfuscate the metadata, this needs support throughout all clients participating in a conversation, otherwise it causes havoc.

(though a trusted server could revert this I guess)

so client and server support yeah

on that note is there somewhere an article or a document that outlines what are the differences in responsibilities for servers and clients

?

i looked at the conformance thing we have and most of the them are both server and client

afaik its only mam and for some reason storing bookmarks that go to server

but would love any pointers

PEP

(i.e. distributing OMEMO keys)

but I don't think there's a single comprehensive document

distributing omemo keys is only for when the client is offline though right?

ah also the groups management

don't think so

so mam and groups are the main things

whatever is in the PEP node (I'm no OMEMO expert) always goes through the server

msavoritias, roster, too :)

(alongside distributing presence)

servers also do various optimisations, such as replying to XEP-0030 queries for known XEP-0115 or XEP-0390 hashes, to not wake up your mobile data modem unnecsesarily.

but roster is optional too to be there is it not?

MAM is also optional

and groups

for certain definitions of optional

whaaaat...

roster is not part of RFC6120 (it's part of RFC6121), but that doesn't mean it's not basically mandated by every client out there.

I will probably look into what prosody supports then

what's your definition of "optional"?

optional is something that makes life easier but we can do without. like you cant get my omemo keys and cant message me if my client is offline

if that makes sense

oh, remember that there's some legacy "offline messages" thing from way before MAM

where the server would just dump any messages received while offline to the first of your clients connecting

I am basically doing some exploratory documentation and reading into writing a client/server thing and that is why I was interested in the seperation between them

right

and OMEMO is in my book definitely optional

I almost never use it.

(except on Snikket)

fair

so the definitions vary greatly

the stuff that is clearly delegated to the server is to me MAM and groups

and you'll have to define what "makes life easier but we can do without" means exactly :-) ✏

and roster and bookmarks

both for obvious reasons i hope

that one is not imo. but I am not sure if its mandated by the protocol

the server needs to know who is in your roster to handle presence probes by other servers correctly

and it needs to know who's in your roster to send presence probes on your behalf when you come online

> and you'll have to define what "makes life easier but we can do without" means exactly :-) basically MAM needs to be there because sometimes we go offline. and with groups its vastly easier to have the group chat being managed by the server instead of one client ↺

(now you could argue that presence is an obsolete concept, but it's in RFC 6121)

msavoritias, MAM only becomes necessary in multi-client scenarios.

in single-client scenarios the legacy offine messages are well sufficient

noob question: Why do we need presence probes instead of just sending a message?

they are unrelated to messages

> in single-client scenarios the legacy offine messages are well sufficient yeah but If I write my server today why would I implement anything but MAM? ↺

you wouldn't

yeah

> they are unrelated to messages im guessing its not omemo either then ↺

presence probes are used by servers to discover the current presence status of remote users with whom you have a presence subscription relation. that's needed because there's no guarantee that your server has the current presence data on file for your contacts if you've been offline for a while (or there has been an s2s disconnection)

because its older

and presence is basically online/offline status, as shown in some clients ✏

but why cant the user just send the message?

and presence is basically online/offline/away/… status, as shown in some clients ✏

oh you can

or just call

but some old-school users like me like to know whether someone is even online

ah. so presense is technically optional

because if they're not, I might as well go over to them next door and tell them what I need them to know _right now_ in person

and one of these things where the rfcs need updating i guess

no, *technically* presence is rfc 6121

so not really optional

you meant "personally presence is optional"

yeah right 😛

technically it is very much not, I think there are even server implementatoins out there which require you to send available presence before you can send IQs or whatnot

here I should also clarify

that I am looking to see what I can do with xmpp by "stretching" it a little bit.

(and some servers won't distribute incoming messages to clients which haven't sent available presence)

yeah makes sense

(unless XEP-280 carbons) ✏

yeah carbons is another one of these things where I am not looking to implement probably

and go directly for im-ng

was about to say that, yes

but yeah I am looking into not implementing a lot of "presence" things

like typing notifications, read notifications and such

Those are messages. :p

if i can also avoid presence all together hmm

Entirely up to clients.

yeah 😛 "presence" in the sense that they are ambient state notifications to the other party

msavoritias, if you have control over both client and server in your setup, you can probably indeed do away with <presence/> stanzas altogether

if you're looking to reuse software, you'll have to at least send available initial presence, but you can otherwise ignore it.

hmm noted.

(except maybe in places like PEP, which are also only distributed to clients which sent presence, which means you may need a presence subscription between users for that to work)

well i am looking ideally to write both a server and a client. but I would like them to be some kind of federated

at some point at least

may I ask why?

why what

because "at some point federated" is often equivalent to "never"

why rewrite the world instead of using things like prosody?

ah. because I am looking into mandating stuff like dnssec by default.

what stops you from doing that with existing things?

I am writing my own to learn guile plus xmpp.

as patches

will definetily look into contributing patches too

i have gajim and prosody in mind for example

and i know that prosody devs do a lot of good work with the modules

the thing i am writing its to experiment with stuff 😛 and its in fossil for these reasons too

> it would be possible to hide the @to localpart+resource from the sending server, and the @from localpart+resource from the receiving server (with heavy protocol modifications of course) Well what I was thinking of was to have the from attribute encrypted in a way that only the recipient can decrypt. If I remember correctly Signal does something similar to obfuscate/encrypt metadata ↺

the reciepietns server needs to know the full reciepient for routing

An error occurs. How do you route it to the sender?

the sender's server would be the entity encrypting the from localpart, so it should do so in a way which allows decryption.

I made some attempts at Venn diagrams for this in a notebook somewhere

What do people usually write in the doap file in <xmpp:since> once a XEP is implemented only in the development version?

the number of the first upcoming version implementing it

We've got `xmpp:since=trunk` for a thing in Prosody

so i wont break anything if i would add `developemtn` or `master` there? (like the tool the creates the overview on xmpp.org)

I usually put NEXT in order to not forget to change it before releasing the next version, then forget to do it.

:)

Could also guess what the next version will be and put that

Link Mauve: I had the same idea, just with `development`

Ok thanks guys :)

Does DOAP-consumers use it for anything but presentation?

I guess they could try matching it with the list of releases that's also in the doap? For example to get the release dates from there? But I don't think anything does this yet

> so i wont break anything if i would add `developemtn` or `master` there? (like the tool the creates the overview on xmpp.org) jubalh: should be fine

alright

I don't think we (prosody) put releases in the DOAP yet

I don't plan to do calculations with `since`

The data explorer thing probably lets you group by version, so that's probably enough