erkanfilesralphm: I just finished the minutes for 2018-12-20... Could you check this before I submit? This is my first try...
erkanfilesOr anybody else?
Ge0rGerkanfiles: I can review as well if you wish. You need somebody to forward them to the lists anyway.
Ge0rG(I'm not on board, but on members)
moparisthebesthas joined
moparisthebesthas left
moparisthebesthas joined
Ge0rG> This server could not prove that it is logs.xmpp.org; its security certificate is from xmpp.org
*sigh*
waqashas left
waqashas joined
Yagizahas left
moparisthebesthas joined
moparisthebesthas joined
freddohas joined
mightyBroccolihas left
benpahas joined
benpahas joined
_purple_bothas joined
_purple_bothas joined
Matthewhas joined
Matthewhas joined
uhoreghas joined
uhoreghas joined
jjrhhas left
Ge0rGhas left
benpahas joined
uhoreghas joined
_purple_bothas joined
Matthewhas joined
lnjhas left
Zashhas left
benpahas joined
_purple_bothas joined
Matthewhas joined
uhoreghas joined
jjrhhas left
jjrhhas left
mightyBroccolihas joined
jjrhhas left
benpahas joined
uhoreghas joined
_purple_bothas joined
Matthewhas joined
lukkechas joined
waqashas left
lukkechas left
lukkechas joined
jjrhhas left
lukkechas left
lukkechas joined
erkanfileshas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
Holgerhas left
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
moparisthebesthas left
moparisthebesthas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
frainzhas left
lukkechas joined
lukkechas left
lukkechas joined
frainzhas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
ralphmhas left
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
redditorhas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
lukkechas joined
lukkechas left
j.rhas joined
Yagizahas joined
krauqhas left
krauqhas joined
mightyBroccolihas left
jjrhhas left
jjrhhas left
!xsf_Martinhas joined
lhas left
mightyBroccolihas joined
pep.has left
lskdjfhas left
Sevehas joined
jjrhhas left
redditorhas left
redditorhas joined
redditorhas left
redditorhas joined
winfriedhas joined
winfriedhas joined
Annhas left
Annhas joined
j.rhas joined
doshas left
UsLhas joined
Lancehas joined
mightyBroccolihas left
Steve Killehas left
Steve Killehas left
mimi89999has joined
mrDoctorWhohas joined
mightyBroccolihas joined
lhas joined
Steve Killehas joined
waqashas joined
lhas left
Alexhas joined
redditorhas left
redditorhas joined
ralphmhas left
Zashhas left
pep.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.
j.rhas joined
lhas joined
mightyBroccolihas left
mightyBroccolihas joined
tahas joined
lhas left
redditorhas left
redditorhas joined
tuxhas joined
krauqhas left
SyndaceWe 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.
Wiktorhas left
valohas left
valohas joined
Lancehas left
Lancehas joined
Lancehas left
Lancehas joined
erkanfileshas joined
j.rhas joined
j.rhas joined
WiktorSyndace, 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.
SyndaceWhat do you mean by "current design"?
SyndaceRevocation is for when you loose a device or you know the keys have been compromised.
WiktorI mean by what Conversations do hehe, if you lose a device then after some time the client will stop encrypting for that decide
WiktorDevice*
SyndaceOkay, that does not use cross-signing though ^^
WiktorYes but it's already working for "revocations" so no need to invent anything new here
Annhas left
WiktorJust keep the same rules for cross signed devices, no need for extra revocations
SyndaceI'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
tahas left
WiktorI'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.
WiktorIf not you risk reimplemening OpenPGP and that's a lot of stuff.
blackmarkethas joined
tahas left
genofirehas left
blackmarkethas left
SyndaceYes 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.
tahas left
WiktorYep, but distributing revocations is a problem. That's why OpenPGP has keyservers to make it hard to remove revocations.
tahas joined
genofirehas joined
WiktorActually 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...
pep.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
pep.And indeed that can be easily blocked by the server
WiktorAnd all that has already been solved by OpenPGP, I just warn that there is a risk of reimplemening square wheel here
pep.That point is clear. That's not what I was replying to
pep.You talked about Matrix, do you have any insight on how they handle this?
WiktorOpenPGP also has signature expiry, you can use that to automatically expire signatures and require re signing if the device is used
WiktorNope, I'm not involved in Matrix that much, the blog post I read only mentioned cross signing by already trusted devices
pep.Right, I read that one as well
redditorhas joined
waqashas left
Yagizahas left
redditorhas joined
Annhas left
Annhas left
uhoregThe (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.
uhoregIt does depend on the server being somewhat trustworthy, but I don't think there's much you can do about it.
SyndaceTrusting the server is not acceptable for OMEMO I'd say.
uhoregIf 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.
Annhas left
pep.Yeah I'm also doubtful, even if that's also a property I would like, in the context of e2ee
redditorhas left
redditorhas joined
jonas’has left
j.rhas joined
redditorhas joined
stevenhas left
lovetoxalso omemo is relying on the server already
pep.Yes it is. A server can just refuse publishing keys
lovetoxif you remove a device from your devicelist, to broadcast to others that its not in use anymore
lovetoxthen this could be just not broadcasted, and other contacts will never know that you dont use the device anymore
SyndaceIt is relying on the server but the only thing the server can do is block OMEMO overall or attempt to MITM.
lovetoxno as i just described
SyndaceOr that, righr
lovetoxit can block "revocation" of devices
jonas’the only use of which would be to attempt MITM, right?
lovetoxyou cant MITM omemo
lovetoxits simply not possible as of to date
Syndacewell if the admin got hands on one of your devices it would make sense for him to block the unpublishing
lovetoxbut you can steal a device
Syndacewhy is it not
lovetoxand then block that this device is revoked
lovetoxbut thats not MITM
pep.lovetox, you can mitm? and it can easily _not_ be detected, (who even reads the list of fingerprints)
pep.Ah hmm
pep.Not MITM
pep.Add yourself in the device list
jonas’yeah, you’re not in the middle, but ... I’d still call this mitm
lovetoxsorry 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
jonas’the effects (can read and inject(?) messages) and the mitigations (validate your bloody fingerprints) are the same
Annhas left
pep.jonas’, inject yes, the original account doesn't even have to know
pep.If OMEMO is based on the fact that the server is not trusted, this is pretty much a fail
lovetoxpep., i cant agree with you on that
lovetoxyou seem to think you can just add a device and then everyone is starting to encrypt all his messages to that
krauqhas joined
pep.Because it's not true?
lovetoxthis is simply not possible if you configure your client correctly
lovetoxyou cant with Gajim
pep.Right, you have a big assumption right there
lovetoxthere will be a popup that tells you, NEW DEVICE do you want to trust?
lovetoxotherwise it will never encrypt to that device
lovetoxthere is no attack as a malicious server, that does not depend on the user actively ignoring to verify fingerprints
jonas’lovetox, and the average user will just accept
lovetoxbut thats true for every encryption
pep.Yes
lovetoxthis has nothing to do with omemo
pep.Well, yes and no. It has to do how it's designed, and what type of users it's targetting
pep.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
lovetoxI could easily write a client that encrypts only to QR code scanned devices
lovetoxthen every device is physically verified
lovetoxthis is a client UI decision, and is not a fail in the protocol
pep.True, you could. I doubt you'd manage to market that
lovetoxyeah of course, lets make compromises, because the thread model is not NSA prove
lovetoxthe thread model is, lets encrypt 99% of my data in a way that 99% of people cant decrypt it
lovetox*profe
pep.proof :)
lovetox*proof
lovetoxdamn it
lovetoxdidnt write that for a long time, and it seemd wrong :D
j.rhas joined
lovetoxno im all for looking into this stuff, but signal protocol or whatever you want to call it, is pretty pretty good
lovetoxthere is really not much left to make better
Ge0rG> 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!
Ge0rGthe challenge is to build a usable client around the signal protocol.
Ge0rGactually, no. The challenge is to build a usable client around any encryption primitive.
lovetoxi agree thats the challenge
Half-Shothas left
Ge0rGI 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
Ge0rGBut what do I know.
lovetoxand in my opinion what we have now, specially in Gajim there is lots of room for improvement before i go and criticise the protocol
Ge0rGif the protocol did it right, you wouldn't have a forest of possible fuckups to solve in your client.
lovetoxGe0rG, i also wrote a already usable openpgp plugin for the current Gajim version, works fine, i didnt impl the secret key transfer yet
lovetoxand you can also make openpgp hard to use
stevenhas left
pep.lovetox, I just tested with conversations and dino, none tell me I've added a new device
Ge0rGBut we only ever specify the wire format, no need to tell developers how to solve the really complicated UX problems.
pep.So I guess that's already a nice set of users not checking
lovetoxpep., because blind trust is activated in C by default maybe?
Ge0rGExcept that for encryption, a UX fail might kill people.
pep.lovetox, of course it is
pep.That's the whole point of Conversations
lovetoxto actually have conversations :D
lovetoxnot care about encryption
pep.I disagree here
lovetoxi agree with that to be honest, lets concentrate less about that crypto mania and more about usable clients
Ge0rGLet's not implement OMEMO.
pep.mod_omemo_mitm when
pep.Just to prove a point
Ge0rGIf you are a political dissident, don't use xmpp. It will get you killed.
waqashas joined
Ge0rGAlso 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
taGe0rG: just out of couriosity, what's your recommendation for endangered persons?
Ge0rGta: 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
sezuanhas left
mimi89999has left
Ge0rGta: I'm not an endangered person, so I didn't do thorough research.
Half-Shothas joined
vaulorhas joined
pep.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
taMw neither, but i am interested in that topic. To secure your privacy yoi almost have to act like a "wanted" person.
taI am aware that XMPP is not ideal for that matter either.
pep.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
taAnd configuring mobile devices to leak as little information as possible is a fight against windmills.
mightyBroccolihas left
lorddavidiiihas joined
taI 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.
Tobiashas left
Tobiashas joined
taSome 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.
lorddavidiiihas left
lorddavidiiihas joined
tahas left
tuxhas left
lorddavidiiihas left
mightyBroccolihas joined
jjrhhas left
jjrhhas left
oliso xmpp was a great idea some time ago, but post snowden...
j.rhas joined
pep.Because pre-Snowden wasn't as bad?
olifor irc like groups use matrix. for one to one use something p2p
pep.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
pep.hint: I don't think it changes much
taDepends on your needs
Half-Shothas left
pep.We already specified the need in the discussion above. "You don't trust your server"
lorddavidiiihas joined
Guushas left
redditorhas left
lhas joined
lhas joined
j.rhas joined
lorddavidiiihas left
erkanfileshas joined
rionhas joined
lorddavidiiihas joined
rionHi. 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.
lovetoxbut how do you get the info about the version of the disco items?
lovetoxwith normal contacts, we exchange presence and we have to do this anyway so we add the version there and save a query
Alexhas left
lovetoxbut you exchange nothing with a MUC or component where you could add the version and save the query
lovetoxthe first every contact is the disco query, so you get to know what that thing is in the first place
lhas joined
rionlovetox: 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.
lovetoxto answer your question, no we dont have something like that for server components
rionbtw about muc. ejabberd already can compute caps for it and send them early on join.
lovetoxthats too late
lovetoxyou have to know if a jid is a muc before you join
rionwell yes. but it's better than nothing
rionis there a place where I can write my wishes for xep improvements?
lovetoxhm its only useful if you dont use MAM
lovetoxyes the standards mailing list
lovetoxstandards@xmpp.org
lovetoxoh rion i spoke too soon
lovetoxthere is an experimental xep who does what you want i think