XSF Discussion - 2024-08-12

As usual, I don't accept the premise of your two types division... But, If you went to the conference, you could meet people irl who met people IRL and signed pgp keys.

I don't get why that matters or is relevant... No one asked how to get pgp keys signed in person

Scroll up to what you wrote (claimed) at 22:44 and 22:56 UTC re pgp. The Debian conference practices would seem to contradict your claims.

No, you misread

Well, I don't doubt your lack of knowing anyone...but that doesn't support a claim of 20 years not working.

> Not working in practice as in not popular? It's not like xmpp is particularly popular either, doesn't mean it doesn't work. as in it doesnt work the way pgp does it at all.

you can of course create another web of trust framework on top of pgp. sequoia is doing some interesting work there

>> nicoco, a private, non-anonymous MUC ? > Yup. I know that they can find each others in the participants list, the thing is, most don't. My friends are probably slow. 😉 nicoco: Same. I've tried getting my non-geek friends to add mutual friends manually, and they complained (paraphrased) "this app takes so much work". ✏ ↺

+1 on that yeah

It's not even about users being slow - it's simply a matter of "software should aim to reduce the user's work."

I think we can learn a lot from Quicksy when it comes to the benefits of (automated) contact discovery

> I've never known anyone who's met anyone IRL and signed their pgp key, and I know a ton of nerds Well, there are XSF people who' ↺

Ack. XSF people who've gone to signings. But given one of them, as I recall, turned up with a 'fake' sample passport...

In my wild days, I've participated in a dozen or more key signing parties.

it was my personal peak concentration for hearing bad George Lucas jokes.

Ge0rG: do you want to relive those glorious days?

mathieui: I'm as glad as anyone that PGP ~is dead~ has gracefully retired.

PGP is not dead https://xmpp.org/extensions/xep-0373.html

secushare also has a few words on how to do contact discovery https://secushare.org/rendezvous that is probably based on this https://secushare.org/aspects aka a MIX/ocap architecture in my view. but as with everything secushare nothing you can actually use today

lissine: statistics from yax.im say: 23 users have PGP keys, 41000 users have OMEMO keys. I stand by my statement.

Many users dislike Omemo's perfect forward secrecy. It's just that xep-373 isn't supported by many clients (only Gajim and profanity), otherwise it'll have more usage (but still less than omemo)

pypi has also removed pgp keys because they didn't offer any security. https://blog.pypi.org/posts/2023-05-23-removing-pgp/ stuff are better signed with minisign or sigstore nowadays for software artifacts

From that article I got the impression that they just removed the pgp signatures, I see no mention of minisign

they havent settled on a solution. minisign and sigstore were what i mentioned. afaik pypi is looking into sigstore as a replacement at some point.

The link to USDOJ subpoenas blog post at the bottom caught my eye. If not too off topic, is there any more info on what that was all about?

> Many users dislike Omemo's perfect forward secrecy. > It's just that xep-373 isn't supported by many clients (only Gajim and profanity), otherwise it'll have more usage (but still less than omemo) I don't think anyone dislikes perfect forward secrecy; people dislike the effects of it (like server-side archiving, etc). ↺

I had a customer once who wanted both e2ee with perfect forward secrecy *and* server-side archival search.

which there are solutions to these tbh

I was hoping XEP-0373 was something to fix the history issues with OMEMO, but it's just the OX XEP 🥲

fugata: it does exactly that.

> I think we can learn a lot from Quicksy when it comes to the benefits of (automated) contact discovery Daniel: please elaborate? I remember seeing a fedi post where you explained that quicksy was not very successful, so I assume you mean contact discovery does not matter that much?

> I had a customer once who wanted both e2ee with perfect forward secrecy *and* server-side archival search. This seems pretty common. People don't want to use PGP as they read on random blog post encryption without forward secrecy is bad but once they set up a new device they complain that they can't decrypt previous OMEMO messages.

which is an implementation fault tbh

Dependsof the threat Model, and why using pfs in the first place

sure. but implementations have two choices: - account for messages and new devices (which there are various ways to do so) - implement pgp, (with sequoia as a hard requirment) and hope that people can understand the difference (they wont)

so first one is probably the safe way here

I plan to eventually have a "forward secrecy on/off" toggle to switch between OX and MLS

that is one way to do it yeah. probably phrased something like "if i lose my device i can recover the messages"

Yeah

MSavoritias fae.ve: Why demand a certain implementation (Sequoia) as hard requirement? I use gopenpgp and don't see why this should not be allowed.

For sure. I think people confuse the way some implementations are used historically with their abilities. Any implementation is fine (modulo bugs)

i said about sequoia because its the only one i know that is actually trying to make a sane interface over pgp and is involved with the rfc to update the openpgp crypto that gnupg is opposed. but true probably it would be better to just not support gnupg or the librepgp group. anyone outside of that should be fine

Even gpg is fine is using v4. Their biggest problem is they have no library

last i heard the gnupg basically threw a tanturm because they dont want to update any cryptography and created their own initiative called librepgp. plus gnupg is the one with the famous horrible UX so any implementation using that is not to be taken seriously imo

Yes, we should define the standard to use (rfc…, v4 or v6) and let people choose whatever they want as long as it complies. Also the interface is more up to the client and not to the pgp lib/client used. I think clients should handle the keys as they do for OMEMO as well and not expect users to fumble with gnupg/sq/*sop etc.

MSavoritias fae.ve: well, it's more that gpg put effort into implementing v5 before it was a standard and then threw a fit when V6 work started and isn't compatible with v5 work they did. Kind of like everyone implementing omemo and then being grumpy about twomemo

I'm not on their side, but it wasn't *only* unreasonable

yeah the keys shouldn't be directly managed. it could be interesting a study on if people understand what they pick as encryption or regret it afterwards

i fear giving a choice for encryption is just the easy choice and is confuse people

Choose [ ] Super secure whistle blower grad security with key mess and forward secrecy breaking archives [ ] Less secure (no forward secrecy or deniability) but for most people 'good enough' encryption with one key per account and working archives

[ ] I want to lose all my messages when my phone is lost or dies [ ] I want to be able to recover some messages when my phone is lost or dies

these are all problems that can be solved tho.

we have already solutions for the mess of keys. and for retriveing the messages

You have a solution for retrieving messages with PFS?

also you absolutely do not know what is 'good enough' encryption for "most" people. whatever most means. and i doubt you can make it so that users can give enough of an informed decision

> You have a solution for retrieving messages with PFS? you mean backups? yes these solutions exists ✏

im talking about people here btw. im sure companies have their own weird requirments and e2ee doesnt make sense for them anyway

Backups of decrypted messages? I guess the premise being that you trust the backup provider more than your server? If done diligently could work I guess

singpolyma, No, it means using non-PFS crypto for backups. There are better[*] solutions like threshold cryptography, which is what PHB is doing on his Mathematical Mesh thing.

> it means using non-PFS crypto for backups. Right. That's why I said what I did about trusting the backup provider

> Backups of decrypted messages? I guess the premise being that you trust the backup provider more than your server? If done diligently could work I guess either server, local or distributed backups yes. it can also be done with a backup "request". as in you ask for the messages and other people encrypt them and send them to you

Wait, does that mean you need to trust that people aren't changing the messages?

for 1:1 chats yeah. you always have trust someone

for group chats mls can probably make it harder to spoof messages

I'm not sure how, beyond asking multiple people and hoping they're not in collusion.

XEP-0045, section 10.1.3 "Creating a Reserved Room" has this as its last paragraph: > If the room owner becomes unavailable for any reason before submitting the form (e.g., a lost connection), the service will receive a presence stanza of type "unavailable" from the owner to the owner's <room@service/nick>. The service MUST then destroy the room, sending a presence stanza of type "unavailable" from the room to the owner including a <destroy/> element and reason (if provided) as defined in the Destroying a Room section of this document. What is the purpose of sending a 'destroy' presence unavailable to the owner that is itself unavailable? RFC 6121 section 8.5.3.2.2. defines that presence unavailable is to be silently ignored by the server, I think.

Also, where would the reason be provided in this scenario?

reading the rfc it says https://www.rfc-editor.org/rfc/rfc9420.html#section-16.9 > MLS is designed to protect the confidentiality and integrity of the group data even in the face of a compromised DS. However, a compromised DS can still mount some attacks. While it cannot forge messages, it can selectively delay or remove them. so you may have missed messages but they cant forge messages. it is explained a bit above where it says: https://www.rfc-editor.org/rfc/rfc9420.html#section-16.5 which says that the messages are signed with the private key of the person and with a shared group key at the time of the epoch. so this is assuming that the person is available during that epoch that wants to forge the message because otherwise they dont have the message or the shared secret of the epoch plus that they have the collaboration of the majority in the group probably? to add the same message with the same counter in there in place of the old one and in an older epoch with a different secret that doesnt exist anymore. because the minute the new account joins there is a new commit and a new secret negotiated so everything before then might as well not exist. i wonder how feasible that attack would be in practise

what i am more interested in is how the Authentication Service would be done in a p2p context. because it seems a lot of trust is put on the server (again) https://www.rfc-editor.org/rfc/rfc9420.html#section-16.10 and given the already weak security of muc on the server things are getting very messy there

Ah, you

Dag nabbit.

You're thinking the DS would replay messages on demand?

hmm. why wouldnt it

found the Mathematical Mesh you said btw. very exciting stuff will give it a read :D

> I plan to eventually have a "forward secrecy on/off" toggle to switch between OX and MLS I've been wondering of that's easier than doing an on/off toggle for key backup ↺

> Backups of decrypted messages? I guess the premise being that you trust the backup provider more than your server? If done diligently could work I guess Matrix backups up the 'ephemeral' keys, and because matrix servers rarely delete anything the ciphertext is still there ↺

The keys are encrypted of course. Doing that with OPAQUE could be neat

re verification, whatsapp seems to think an append only log you can audit is the way to go https://engineering.fb.com/2023/04/13/security/whatsapp-key-transparency/

XEP-0045 MUC has strange things in it: - I can set a language, but only one. Multi-lingual MUCs are common nowadays, e.g. practically all technical MUCs in Germany are "de", but allow "en", too, or vice versa. Other languages are not accepted, because moderators can't know, if the content is unwanted. Why is it not a list of language codes? - I can set the max. participants to 10, 20, 30, 50 or 100. But neither to 42, nor to 1024. While 42 is probably not relevant (just set it to 50), higher values than 100 make sense, IMHO. Why is it a list of predefined values instead of an integer?

> You have a solution for retrieving messages with PFS? singpolyma: yes. Device-to-device MAM, either through the server with SCE or via direct webrtc data stream ↺

That's what all the other "super mega ultra secure against everything but a $5 wrench" PFS messengers do

Oh and Signal uploads whole archives to the server encrypted by a 4 digit numeric pin code, not sure how this in particular counts as PFS anymore but only a few complain...

Device to device MAM is probably a good idea independently of encryption. I reckon that a lot of public xmpp providers have storage times that are shorter than people would like to keep message history for

> singpolyma: yes. Device-to-device MAM, either through the server with SCE or via direct webrtc data stream This is explicitly not an option for the case I described (where your lose or destroy your phone) ↺

What if you had another client you could install on a server you control?

Maybe a multi-user client that someone you trust could operate for you?

dwd: ooh, yes! and then you could just use that client instead of your server!

> Device to device MAM is probably a good idea independently of encryption. I reckon that a lot of public xmpp providers have storage times that are shorter than people would like to keep message history for I agree. ↺

>> singpolyma: yes. Device-to-device MAM, either through the server with SCE or via direct webrtc data stream > This is explicitly not an option for the case I described (where your lose or destroy your phone) Users are used to that too right? Unless you enable the pin thing :P ↺

debacle: I'm not sure if the values/options in the list of muc#roomconfig_maxusers are predefined. I _think_ you can offer a list that contains any value?

(which would be an ugly hack at best)

I suspect that this (as well as the singular language) stems from a time where use cases were 'simpler' (for lack of a better word).

Yep servers can offer anything in that list, and it's text so "unlimited" or the like can be offered I suppose

I'd be very curious what breaks in clients if a server just sends multiple languages. I'm willing to bet nothing will break and your worst case is clients showing only the first language in the list

re: langs should probably just define a new field for the multiple languages acceptable in a muc, until then throw it in the subject or description

> I'd be very curious what breaks in clients if a server just sends multiple languages. I'm willing to bet nothing will break and your worst case is clients showing only the first language in the list I suspect few, if any, clients expect multiple body tags. I don't think anything I've ever written does. ↺

Similarly the xml:lang element on streams that I vaguely remember exists.

That's a giant footgun/anti-feature/critical-security-issue depending on who you talk to also...

All XMPP client libraries I've seen end up with a "getBestBody(lang)" method which just returns 1 to display

> Device to device MAM is probably a good idea independently of encryption. I reckon that a lot of public xmpp providers have storage times that are shorter than people would like to keep message history for Want to have that for my IoT application: An XMPP enabled data logger has older measurement data stored and it would be very cool to be able to fetch it with MAM queries. ↺

If you don't need encryption it should just work today probably, no?

Worded differently, I don't think there's anything preventing a client from implementing answering mam queries and another client sending it queries right now is there?

Just for e2e backfill specifically you wouldn't want to use that without SCE

> If you don't need encryption it should just work today probably, no? Maybe we "just" need to implement it. We are in the convenient position of having written both the IoT side client (C, libstrophe) and the human side clients (Python, slixmpp and JS, strophe.js). And in the inconvenient position of no time, no money, no exceptionally XMPP skilled staff. But maybe we can try it anyway. ↺

The list of things I "just" need to implement... 💀 Patiently awaiting XEP-1000: Unlimited Free Time

>> I'd be very curious what breaks in clients if a server just sends multiple languages. I'm willing to bet nothing will break and your worst case is clients showing only the first language in the list > I suspect few, if any, clients expect multiple body tags. I don't think anything I've ever written does. Sure. That's a whole different thing ↺

Tagging body elements with lang attributes makes sense, even if sending only one body per message. Just to declare "this message is in English" and your TTS software should read it with a strong Cockney accent.

> Tagging body elements with lang attributes makes sense, even if sending only one body per message. Just to declare "this message is in English" and your TTS software should read it with a strong Cockney accent. debacle: does tagging bodies make sense though? In multilingual rooms it's common to write one message in a mix of languages. But even when you write in one or the other, are you going to toggle some switch to say which it was before pressing send? ↺

I should look at the traffic to this MUC... I bet in practice a fair number of messages say lang=de even though they are all English

it makes sense if you can do it correctly, but I agree the ux can be tricky

mostly it makes sense for bots

Is there any "prior art" to language tagging in messaging?

xmpp is the first I can recall hearing about language stanzas

I agree it makes sense for bots or other automated software. But never in the case of messages between humans imho.

SavagePeanut: I think XMPP unfortunately inherited it "for free" from XML

Interesting

Even for bots in a group chat it makes the most sense for everyone to see the same IMO For not in a group chat, this isn't necessary

Mastodon allows me to tag my posts ("toots") with a language. IIRC, it even tries to guess the right language automagically. Which is nice for others, who can filter on language. Not sure, how useful this is in the IM use case, though.

True, for 1:1 the bot can just send the lang you want

> Mastodon allows me to tag my posts ("toots") with a language. IIRC, it even tries to guess the right language automagically. Which is nice for others, who can filter on language. Not sure, how useful this is in the IM use case, though. debacle: silly though isn't it? If the right language can be guessed automatically then we don't need the sender to send it at all 😁 ↺

Automated language guessing is easily fooled in short posts with slang, abbreviations, or names from what I've seen

Not in a medium where you have one writer and many readers. That way the language is only guessed once (and maybe even corrected) on the authors side.

For a11y, having correctly tagged messages is useful, just for the TTS.

the "maybe even corrected" is key. you need UI for that

Can't mix languages either

well no, that's going to be either unspecified or specify the main language, depending on what the author is doing

> I plan to eventually have a "forward secrecy on/off" toggle to switch between OX and MLS This honestly seems like the perfect, no compromise solution. A "Perfect Forward Secrecy" toggle, that is disabled by default. It's less friction for the average person who doesn't really careabout PFS and would rather have recoverable messages, while also appeasing the "E2EE _must_ happen by default" crowd. Anyone who knows about or cares about PFS should of course trivially be capable of toggling the setting without it being a UX issue.

The problem I see with that is that you and your contacts have to agree on which encryption method to use (and spoiler: they won't)

Whereas most of the traditional solutions involve using PFS, and then (optionally) weakening it for UX purposes (via backups or decryption requests)

> Automated language guessing is easily fooled in short posts with slang, abbreviations, or names from what I've seen more than that. for short messages, it gets progressively more intractable. consider single emoji messages (which my tooling regularly tags as being in Telugu, for whatever reason) ↺

MattJ, ah hmm yeah didn't think of that lol

Also OMEMO vs PGP isn't only PFS or not there's a ton of other trade-offs