XSF Discussion - 2019-01-02

ralphm: I just finished the minutes for 2018-12-20... Could you check this before I submit? This is my first try...

Or anybody else?

erkanfiles: I can review as well if you wish. You need somebody to forward them to the lists anyway.

(I'm not on board, but on members)

> This server could not prove that it is logs.xmpp.org; its security certificate is from xmpp.org *sigh*

https://wiki.xmpp.org/web/Main_Page somebody added "Quickstart for developers" on the main page, but it points nowhere. There's also "Modern Login Procedure" that points nowhere. Even if that can be a good idea I vote to remove them while they're empty.

We had a discussion about OMEMO key cross-signing and without giving any further context it seems like revocation is the biggest problem which needs some smart ideas. If we do it the GPG-way we need some sort of revocation-cert. The problem is where to upload the revocation cert to, because a malicious admin could block uploading those or remove them from PEP/whatever.

Syndace, why is cross signing intermixed with revocations? As far as I understand cross signing is for extending trust to new keys. If the device is not used for some time it's "revoked" automatically in current design already. That'd cover common scenarios like device migration.

What do you mean by "current design"?

Revocation is for when you loose a device or you know the keys have been compromised.

I mean by what Conversations do hehe, if you lose a device then after some time the client will stop encrypting for that decide

Device*

Okay, that does not use cross-signing though ^^

Yes but it's already working for "revocations" so no need to invent anything new here

Just keep the same rules for cross signed devices, no need for extra revocations

I'm sorry but those are two completely different things. One is publishing cryptographic signatures to tell others that you trust a certain key and the other is some client-side timeout logic that is not specified or cryptographically backed at all

I'd keep it lightweight, like in Matrix, the cross signing signature should be created by already trusted device and add trust only once, then the trusted device should be treated like any other.

If not you risk reimplemening OpenPGP and that's a lot of stuff.

Yes that's the goal. The thing is that revocation cannot be ignored really. You need a mechanism to tell people that a key is not trustworthy any more. Otherwise an attacker could use compromised keys to cross-sign as many malicious devices as he likes to.

Yep, but distributing revocations is a problem. That's why OpenPGP has keyservers to make it hard to remove revocations.

Actually I had an idea how to use OpenPGP (on Android through OpenKeychain) to distribute trusted devices set. But that's including OpenPGP in the solution...

Wiktor, if you implement a way to say "I trust this device" to others, you will also need a way to say "I don't trust this device anymore", I don't think there's any need for arguing that one is not needed

And indeed that can be easily blocked by the server

And all that has already been solved by OpenPGP, I just warn that there is a risk of reimplemening square wheel here

That point is clear. That's not what I was replying to

You talked about Matrix, do you have any insight on how they handle this?

OpenPGP also has signature expiry, you can use that to automatically expire signatures and require re signing if the device is used

Nope, I'm not involved in Matrix that much, the blog post I read only mentioned cross signing by already trusted devices

Right, I read that one as well

The (work-in-progress) proposal for cross-signing in Matrix is at https://github.com/matrix-org/matrix-doc/pull/1756, which uses a master key for signing device keys, rather than having devices sign each other and trying to navigate an arbitrary trust graph. And rather than revocations, we're just nuking the master key and replacing it with a new one.

It does depend on the server being somewhat trustworthy, but I don't think there's much you can do about it.

Trusting the server is not acceptable for OMEMO I'd say.

If you can figure out a way to do it without having to trust the server to distribute things properly, I'd be very interested in seeing it. It would be very desirable to have that property, but I haven't been able to figure it out yet.

Yeah I'm also doubtful, even if that's also a property I would like, in the context of e2ee

also omemo is relying on the server already

Yes it is. A server can just refuse publishing keys

if you remove a device from your devicelist, to broadcast to others that its not in use anymore

then this could be just not broadcasted, and other contacts will never know that you dont use the device anymore

It is relying on the server but the only thing the server can do is block OMEMO overall or attempt to MITM.

no as i just described

Or that, righr

it can block "revocation" of devices

the only use of which would be to attempt MITM, right?

you cant MITM omemo

its simply not possible as of to date

well if the admin got hands on one of your devices it would make sense for him to block the unpublishing

but you can steal a device

why is it not

and then block that this device is revoked

but thats not MITM

lovetox, you can mitm? and it can easily _not_ be detected, (who even reads the list of fingerprints)

Ah hmm

Not MITM

Add yourself in the device list

yeah, you’re not in the middle, but ... I’d still call this mitm

sorry if you dont verify the fingerprint, then its also not a MITM attack, its a I hope this user doesnt know what he does attack

the effects (can read and inject(?) messages) and the mitigations (validate your bloody fingerprints) are the same

jonas’, inject yes, the original account doesn't even have to know

If OMEMO is based on the fact that the server is not trusted, this is pretty much a fail

pep., i cant agree with you on that

you seem to think you can just add a device and then everyone is starting to encrypt all his messages to that

Because it's not true?

this is simply not possible if you configure your client correctly

you cant with Gajim

Right, you have a big assumption right there

there will be a popup that tells you, NEW DEVICE do you want to trust?

otherwise it will never encrypt to that device

there is no attack as a malicious server, that does not depend on the user actively ignoring to verify fingerprints

lovetox, and the average user will just accept

but thats true for every encryption

Yes

this has nothing to do with omemo

Well, yes and no. It has to do how it's designed, and what type of users it's targetting

People come to us saying "OMEMO is the #1 feature I want. I don't consider a client otherwise" and they don't understand what it means

I could easily write a client that encrypts only to QR code scanned devices

then every device is physically verified

this is a client UI decision, and is not a fail in the protocol

True, you could. I doubt you'd manage to market that

yeah of course, lets make compromises, because the thread model is not NSA prove

the thread model is, lets encrypt 99% of my data in a way that 99% of people cant decrypt it

proof :)

*proof ✏

damn it

didnt write that for a long time, and it seemd wrong :D

no im all for looking into this stuff, but signal protocol or whatever you want to call it, is pretty pretty good

there is really not much left to make better

> lets encrypt 99% of my data in a way that 99% of people cant decrypt it I don't want 99% of people to decrypt my data! Only a selected subset of a few persons!

the challenge is to build a usable client around the signal protocol.

actually, no. The challenge is to build a usable client around any encryption primitive.

i agree thats the challenge

I think that OpenPGP has better UX than OMEMO, and Matrix seems to agree. A per-account master key that is the root of all trust for a user is so much more transparent and usable than N device keys on your side and M device keys on each of your contact's side with NxM trust relationships

But what do I know.

and in my opinion what we have now, specially in Gajim there is lots of room for improvement before i go and criticise the protocol

if the protocol did it right, you wouldn't have a forest of possible fuckups to solve in your client.

Ge0rG, i also wrote a already usable openpgp plugin for the current Gajim version, works fine, i didnt impl the secret key transfer yet

and you can also make openpgp hard to use

lovetox, I just tested with conversations and dino, none tell me I've added a new device

But we only ever specify the wire format, no need to tell developers how to solve the really complicated UX problems.

So I guess that's already a nice set of users not checking

pep., because blind trust is activated in C by default maybe?

Except that for encryption, a UX fail might kill people.

lovetox, of course it is

That's the whole point of Conversations

to actually have conversations :D

not care about encryption

I disagree here

i agree with that to be honest, lets concentrate less about that crypto mania and more about usable clients

Let's not implement OMEMO.

mod_omemo_mitm when

Just to prove a point

If you are a political dissident, don't use xmpp. It will get you killed.

Also there is no strong binding between the JID and the keys, so OMEMO ends up being an encryption overlay with opaque rules (superset of device IDs of all the participant JIDs) on top of a message routing overlay with opaque rules on top of a federated client - server - server - client overlay on top of TCP IP

Ge0rG: just out of couriosity, what's your recommendation for endangered persons?

ta: depends on who's after you. NSA - don't use Smartphones. Russians - don't use Telegram. Other countries - use Apple devices and Signal with a burner number from an American VoIP service

ta: I'm not an endangered person, so I didn't do thorough research.

Tbh I understand the "privacy by default" bits and I agree with that. I would want to reach a level where people still have some margin to do their research when they suspect they're being targeted. Atm it's probably to late when you reach this conclusion

Mw neither, but i am interested in that topic. To secure your privacy yoi almost have to act like a "wanted" person.

I am aware that XMPP is not ideal for that matter either.

I don't think any solution out there is tbh, you can use bits and pieces of some solutions, but the most effective one is certainly to act as a commoner

And configuring mobile devices to leak as little information as possible is a fight against windmills.

I can not act like most commoners, i don't want to use closed Software (dont get me started on hardware, its a pity). So i always stand out of the masses. That's why i like to encrypt stuff. Since i would stand out my bitstreams sourroubding me shall not be plaintext. Like i dont run around with Information about me printed on my clothes.

Some real p2p solution routed through some onion protocol, verified only in person and used on fully encrypted devices with plausible deniabillity is probably the safest way to not leak content of your Conversation, but will be obvious as hell to agencies.

so xmpp was a great idea some time ago, but post snowden...

Because pre-Snowden wasn't as bad?

for irc like groups use matrix. for one to one use something p2p

I'd be interested to know if matrix actually helps here, or if it's more or less the same issues and you have to trust the server somewhat

hint: I don't think it changes much

Depends on your needs

We already specified the need in the discussion above. "You don't trust your server"

Hi. I'm looking at "6.3 Stream Feature" of caps xep. It's nice. But is there something similar for services list (disco#items) and their versions? I mean I'd like to cache not just jabber.ru but conference.jabber.ru, upload.jabber.ru and other services of my server.

but how do you get the info about the version of the disco items?

with normal contacts, we exchange presence and we have to do this anyway so we add the version there and save a query

but you exchange nothing with a MUC or component where you could add the version and save the query

the first every contact is the disco query, so you get to know what that thing is in the first place

lovetox: no idea how to do this properly. for example if caps computation of jabber.ru would also include conference.jabber.ru that would be enough for me.

to answer your question, no we dont have something like that for server components

btw about muc. ejabberd already can compute caps for it and send them early on join.

thats too late

you have to know if a jid is a muc before you join

well yes. but it's better than nothing

is there a place where I can write my wishes for xep improvements?

hm its only useful if you dont use MAM

yes the standards mailing list

standards@xmpp.org

oh rion i spoke too soon

there is an experimental xep who does what you want i think

at least in part

https://xmpp.org/extensions/xep-0390.html#usecases-stream-feature

390?

thats would be also the place to comment for improvements because its experimental

115 will never change

also for the MUC case there is another problem

the MUC component has caps but they are not that useful

because every MUC jid itself can have different caps

interesting

yeah but also here again, server caps yeah nice

but what you even more need are your account caps

well I just sent the email about xep-0390 updates. I hope it's not lost since I don't have any notifications about its destiny :)

yeah takes some minutes until it shows up

you registered on the list though?

nope..

em yeah i maybe should have mentioned that ^^^^

dont know if it allows to post for unregistered users

https://mail.jabber.org/mailman/listinfo/standards

should I send "register" or something ?

ok

hm rion no mom

seems you dont need to register

the registration is for subscribing

here you can look if it is posted

https://mail.jabber.org/pipermail/standards/

ah damn rion

it says it

Note: To cut down on spam, you must be subscribed to this list in order to post!

I see. I'll resend :)

just subscribed

it's there now

gratz on your first post :D

=))