jonasw18:38:57 lovetox> one could do it that way, but then you would have to check from time to time, if your db stored prekeys are really the ones that are published
you have to do that anyways because PEP services tend to "forget" your stuff from time to time
Guushas left
Guushas joined
Guushas left
Guushas joined
Martinhas left
mrdoctorwhohas joined
Guushas left
Guushas joined
lnjhas joined
kasper.dementhas joined
kasper.dementhas joined
karphas left
karphas joined
kasper.dementhas left
mikaelahas joined
Dave Cridlandhas left
Dave Cridlandhas joined
rishiraj22has left
Dave Cridlandhas left
Dave Cridlandhas joined
kasper.dementhas joined
labdsfhas left
Guushas left
Guushas joined
alacerhas joined
Guushas left
Guushas joined
Ge0rGIsn't it awesome how the xmpp and OMEMO identity models extend each other?
jonaswI sense sarcasm
kasper.dementhas joined
rishiraj22has left
GuusGe0rG, sarcasme? Nahhh...
la|r|mahas joined
Guusraises fist to autocorrect.
lskdjfhas joined
flowGe0rG, while it's trivial to change that?
Dave Cridlandhas left
Dave Cridlandhas joined
kasper.dementhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Martinhas left
Ge0rGflow: one of the strong opinions that I hold is: if you want cryptographic identities, you should have a protocol using those as a first-level citizen, not tacked upon another routing protocol
labdsfhas joined
marchas joined
labdsfhas left
labdsfhas joined
flowGe0rG, I know. But what do you suggest an xmpp based e2ee protocol should do? Using the public key as one's JID localpart?
mikaelahas left
Guushas left
Guushas joined
moparisthebesthas joined
Ge0rGflow: I think there needs to be a stronger cryptographic link between the user identity, the key material and the JID.
Ge0rGflow: if I was doing things, I'd go with user keys that contain a signature of the JID, plus maybe an S/MIME like CA system
flow"signature of the JID"?
flowor a signed statement of the user's JID?
mikaelahas joined
Ge0rGThe latter.
flowI'm also not sure how that prove ownership of the JID
Ge0rGIt doesn't. But it means you can't move a key to a different JID
flowAnd preventing that is desirable because?
Nekithas left
Nekithas joined
marchas left
Guushas left
Guushas joined
Ge0rGflow: I'm not sure. It's just a bad gut feeling, nothing specific. Maybe abuse of sloppy implementations leading to impersonation of other users...
labdsfhas left
labdsfhas joined
rionhas left
404.cityhas joined
flowGe0rG, So if you would be designing things, the main difference would be an additional signed statement of the JID and that only because of a gut feeling that it would possibly beneficial. Or did I miss something?
kasper.dementhas joined
Guushas left
Guushas joined
Steve Killehas left
Steve Killehas left
Ge0rGflow: the main difference is: I would go with a two or three layer architecture. A user has their identity key (or primary device key), and signs their secondary keys. Plus a means to have a CA signing user keys bound to JIDs
Steve Killehas joined
Guushas left
Guushas joined
labdsfhas left
Guushas left
Guushas joined
flowLet me focus on the CA thingy first: What is the advantage over a CA verifying the "identity" by signing user keys compared to the public key in PEP? If you consider Let's Encrypt, then LE just checks that you have control over a certain "namespace", which is pretty much what public key in PEP provides.
flowWhat additional benefit do you envison could a CA provide?
404.cityhas left
Guushas left
Guushas joined
Guushas left
Guushas joined
kasper.dementhas joined
matlaghas left
Ge0rGflow: good point. A public CA doesn't help in needing to trust the server, and no amount of OOB will help
andyhas joined
andyhas left
andyhas joined
Ge0rGA corporate CA might help, but then it's probably operated by the same people the server is
mrdoctorwhohas left
mrdoctorwhohas left
danielhas left
danielhas joined
Martinhas left
404.cityhas joined
Martinhas left
Martinhas left
Martinhas left
Martinhas left
Martinhas joined
Martinhas left
Dave Cridlandhas left
Dave Cridlandhas joined
mrdoctorwhohas joined
la|r|mahas joined
la|r|mahas joined
kasper.dementhas joined
Ge0rGThe major problem I see with OMEMO is multi-device key management. A client message of "You seem to have added a new device at 12:10, with the following fingerprint: ... - correct? [Yes] [No]" with a cross-key signing is vastly better than forcing every one of your contacts to manually verify that fact.
j.rhas joined
jubalhhas joined
j.rhas left
muppethhas joined
muppethhas joined
danielhas left
danielhas joined
lskdjfhas left
SyndaceGe0rG: I like the idea a lot! Has this been discussed before?
Ge0rGSyndace: I suggested that to daniel back when OMEMO was being designed.
Ge0rGThe idea was not approved.
SyndaceHmm, is there a mailing list thread or do you remember the reason?
Ge0rGApparently because automatically trusting a new key which is signed by your friend's old key is a security issue.
Ge0rGOr maybe because signing keys is not trivial. Or both.
danielWhy not share the key?
danielThat seems easier than cross signing
Ge0rGdaniel: what exactly do you mean by "share the key"
danielUsing the same key
danielLike OX
Ge0rGdaniel: ah, a user key as opposed to a device key
SyndaceHow do you get the key to the new device
Ge0rGSyndace: QR code with a red border:P
danielYeah. Or put it in the cloud
SyndaceTrue, but then again, if one device gets compromised, all of them are
Ge0rGSyndace: yes
Ge0rGSyndace: but that doesn't matter in practice.
danielAnd that's the same as cross signing
Ge0rGSyndace: if one if your devices is compromised, the attacker gets the local history of that device and everything sent to you
SyndaceThe cross signing issues don't matter as well
Ge0rGdaniel: as stated above, I prefer user keys to device keys.
Ge0rGdaniel: I thought that OMEMO required device keys anyway, so a two-tier key arch was my second best suggestion
jonaswdaniel, no, it’s not the same as cross-signing. a malicious key added by cross-signing can be removed individually and the damage is contained. if all your devices share the same key, you have to roll your key over entirely to fix the damage. right?
Ge0rGor cross-signing
danielHow do you revoke a key though
Ge0rGstart with a new user key.
danielI mean in case of device keys
danielWhat I'm saying is that I don't see the benefits of cross signing of sharing the private key
Ge0rGdaniel: you *could* add revocations to cross-signatures.
jonaswhm
Ge0rGthe point that I made in the beginning (and am still making) is: with the user managing their own keys, you have O(1) key management overhead. With the contacts managing the user's keys you have O(N) for N contacts, and you have zero decision agency
Ge0rGdid Daniel just buy a new Pixel phone, or is the NSA impersonating? How am I supposed to know?
danielIt's not news that trust is hard
Ge0rGdaniel: and you are making it even harder.
rishiraj22has left
danielThan?
danielOtr?
Ge0rGdaniel: harder than needed
danielOtr allowed for funny questions that I didn't knew the answer to
danielThat was pretty fun
Ge0rGdaniel: are you still on holiday? Have a nice time and let's talk seriously when you're back
j.rhas joined
lumihas joined
la|r|mahas joined
kasper.dementhas joined
rishiraj22has left
rishiraj22has joined
rishiraj22has left
rishiraj22has joined
kasper.dementhas left
kasper.dementhas joined
Guushas left
Dave Cridlandhas left
Guushas joined
Guushas left
Dave Cridlandhas left
Guushas joined
kasper.dementhas left
danielhas left
danielhas joined
andyhas left
jubalhhas joined
danielhas left
danielhas joined
intosihas joined
doublehas left
doublehas joined
flowGe0rG, I still don't know how "xmpp and OMEMO identity models extend[ing] each other" fits into the picture, and what you suggest should change
danielhas left
danielhas joined
remkohas joined
kasper.dementhas joined
Ge0rGflow: apparently it wasn't clear to everybody. My statement was utterly sarcastic.
flowGe0rG, so besides cross-signing keys, you are happy with omemo?
Ge0rGflow: I'm happy with ignoring its existence.
Dave Cridlandhas left
flowIt appears you are not very good at it
Dave Cridlandhas left
404.cityhas left
Dave Cridlandhas left
Ge0rGflow: for practical matters, I am.
Dave Cridlandhas left
Dave Cridlandhas left
kasper.dementhas joined
danielhas left
danielhas joined
Dave Cridlandhas left
Valerianhas joined
Dave Cridlandhas left
jubalhhas joined
Dave Cridlandhas left
danielhas left
Ge0rGobviously, I can't completely ignore it with my Council member hat on.
danielhas joined
kasper.dementhas joined
kasper.dementhas left
kasper.dementhas joined
nycohas left
nycohas joined
Syndacealright honestly, why is the hate against omemo so huge in this whole community? I haven't had problems with it, not one single time.
kasper.dementhas joined
Syndacebecause checking fingerprints is a pain? because "This message is OMEMO encrypted, your client does not seem to support it"?
danielA little bit of both probably. And people also like to complain about things
winfriedhas joined
Syndacethat's far from enough reason to spread such hate
danielThat's the internet
KevI don't think anyone /hates/ it, it's a protocol. I think several people see there are issues with it.
Ge0rGAnd other people think that E2EE should be enforced upon everyone, which leads to hate indeed.
MattJthat isn't specific to OMEMO
Ge0rGE2EE by means of OMEMO.
Ge0rGAnd then non-technical users complain that their messages don't get delivered, and we have one *additional* place to look for.
MattJSomeone spent months trying to contact me once, but they had mod_require_otr enabled on their server and I couldn't reply
MattJand the only contact I had for them was their JID
MattJI had a similar situation where I logged into my account with Conversations to test something, and then a bunch of people couldn't message me anymore
Ge0rGMattJ: should've sent them "?OTRv2 hi please disable mod_require_otr"
jonaswGe0rG, more than one place, because OMEMO is such a mess of moving parts
Ge0rGMattJ: yes, publishing an OMEMO pre-key wreaks havoc to all your other clients.
MattJI don't consider myself an "OMEMO hater" though, I think I've rarely mentioned it... I've many other things to complain about before I could get to that :)
MattJjonasw, is it such a mess?
Syndace> MattJ: yes, publishing an OMEMO pre-key wreaks havoc to all your other clients.
What?
jonaswMattJ, with the unstable PEP implementations out there and inconsistency in handling of OMEMO messages with and without surrogate body (on all levels), yes
MattJBoth seem like things that could be relatively easily fixed
MattJA non-PEP key distribution protocol would be pretty trivial
andyhas joined
Ge0rGMattJ:
> Both seem like things that could be relatively easily fixed
The story of XMPP.
MattJGe0rG, some things are more easily fixed than others :)
MattJOMEMO does not seem like our worst problem by far
kasper.dementhas joined
MattJSyndace, some of my clients don't support OMEMO, I don't particularly want to use OMEMO either
SyndaceWhat about: When starting a new chat, the client sends the messages unencrypted in the message body AND encrypted using OMEMO at the same time and based on whether the response is OMEMO encrypted the client decides whether to stick with omemo or go on plaintext
MattJSyndace, I think my problem is more with the way Conversations enforces it, than the protocol
Ge0rGSyndace: doesn't work in multi-client scenarios
SyndaceWhat does mutli client scenario mean? group chat?
MattJSyndace, multiple clients on the same account
MattJwhich just about every XMPP developer has
SyndaceTrue, all of them need OMEMO to receive the message
Ge0rGall of them need to support OMEMO and have their prekey published and trusted by the sender
Ge0rGthat's a large number of moving parts.
Syndaceyeah i see
Ge0rGespecially if you test multiple desktop clients, multiple mobile clients and do web sessions from time to time
vanitasvitaehas left
Ge0rGso you either end up with one client polluting your PEP with keys, leading to all your contacts sending you garbage, or with other corner cases of the protocol
KevAs long as clients don't go enabling omemo for you automatically, which would obviously be broken, I don't see this as particular problem.
KevOr, rather, not something that can be solved.
KevBecause once you hit the "I want to e2e" switch, you *want* to avoid non-e2e clients getting plaintext.
Ge0rGKev: I've heard that Conversations will auto-enable E2EE.
KevAnd so you're just not going to flick that switch if you want to use non-e2e clients. Irrespective of whether that's omemo or other.
jonasw(you get a warninng and an option to disable when you send a message then)
Ge0rGBesides of this, there is no secure way to communicate the status of that hypothetical "I want to e2ee" switch.
rishiraj22has left
jonasw't
Ge0rGnow attempts to rhyme "e2ee" to "break free"
KevGe0rG: Well, there's HSTS-ish at least.
KevGe0rG: You want to rhyme it to "to break free"
KevThen it works.
Ge0rGKev: except that HSTS relies on a semi-corrupt CA hierarchy
MattJSyndace, and here you get the problem described by XMPP developers. When we (e.g. I'm a server developer) have to deal with users who encounter these problems and want to know why their messages are not being delivered... it's extremely difficult to help them
KevDo I not mean HSTS? I mean "Ok, I'm telling you now, don't use me in the future if I stop encrypting", anyway.
Ge0rGI don't want to be used by Kev
Ge0rGirregardless of E2EE
MattJSyndace, I think that could be solved with better tooling (as well as improving client UIs)
jonaswGe0rG, lol
KevThat's what you think, but you're mistaken (Ge0rG)
jonaswget a room
tahas joined
Ge0rGjonasw: if only MUC invitations were working reliably.
SyndaceI think it's a very bad idea that clients enable encryption even if they know that one of the receiving devices does not support it. Silently dropping messages is a super bad idea confusing WhatsApp-level users
Ge0rGSyndace: there is no notion of "user's devices" so it's impossible to know whether all devices support OMEMO
jonaswSyndace, problem is: if you don’t do that, servers (which are the bad guys™ in the e2ee scenario) can trivially downgrade you to plaintext
Kevjonasw: They have to do it from the get-go, though.
jonaswKev, in your case, yes
KevWell, depending on exactly what's implemented :)
KevRight.
404.cityhas joined
404.cityhas left
doublehas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Dave Cridlandhas left
Dave Cridlandhas left
kasper.dementhas joined
kasper.dementhas joined
mrdoctorwhohas left
intosihas joined
danielhas left
danielhas joined
kasper.dementhas left
kasper.dementhas joined
vanitasvitaehas left
kasper.dementhas left
Guushas left
Guushas joined
blablahas joined
Guushas left
Guushas joined
blablahas joined
kasper.dementhas joined
karphas left
karphas joined
blablahas joined
Guushas left
Guushas joined
Guushas left
Guushas joined
winfriedhas joined
Dave Cridlandhas left
kasper.dementhas joined
Zashhas joined
winfriedhas joined
jerehas joined
kasper.dementhas joined
rishiraj22has left
Steve Killehas left
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
blablahas joined
rishiraj22has left
Holgerhas left
mimi89999has left
kasper.dementhas joined
mrdoctorwhohas joined
tahas left
andyhas left
kasper.dementhas joined
winfriedhas left
Guushas left
Guushas joined
winfriedhas joined
Str4tocasterhas joined
Guushas left
Guushas joined
Guushas left
Guushas joined
Guushas left
Guushas joined
Guushas left
Guushas joined
ralphmhas joined
intosihas left
doshas joined
matlaghas left
marchas joined
doshas left
doshas joined
Str4tocasterhas left
kasper.dementhas joined
flowhas left
Kevhas left
kasper.dementhas joined
Str4tocasterhas joined
Str4tocasterhas left
Steve Killehas left
vanitasvitaehas left
Guushas left
Guushas joined
Chobbeshas joined
Guushas left
Guushas joined
Guushas left
Guushas joined
GuusMade it just in time 🙂
MattJThe question is, who else did? :)
GuusYou, for one. 🙂
MattJnyco, around?
MattJralphm seems to have been popping in and out, I think he's on mobile
Guusnyco mailed that he was not going to be here today.
kasper.dementhas joined
GuusMartin?
MattJOh, missed that
MattJOh, Gmail marked that thread as "Not important" and I overlooked it
Guusthat'll teach you to have such a filter activated on my name. 🙂
rishiraj22has left
GuusShall we try this again next week?
MattJYeah, I think so
MattJbtw, Martin != Martin Hewitt
intosihas left
intosihas joined
Guusah. didn't know, tx
Guusok, I'm off for a bit then. ttyl!
MattJSee you :)
kasper.dementhas joined
Guushas left
doshas left
doshas joined
vanitasvitaehas left
Dave Cridlandhas left
kasper.dementhas left
vanitasvitaehas left
Alexhas joined
vanitasvitaehas left
vanitasvitaehas left
doshas left
matlaghas joined
matlaghas joined
tuxhas joined
kasper.dementhas joined
jjrhhas left
jjrhhas left
danielhas left
danielhas joined
jjrhhas left
kasper.dementhas left
kasper.dementhas joined
doshas joined
lskdjfhas joined
mrdoctorwhohas joined
Guushas left
Guushas left
vanitasvitaehas left
Guushas left
vanitasvitaehas left
vanitasvitaehas left
rishiraj22has left
rishiraj22has left
vanitasvitaehas left
Ge0rGhas left
rishiraj22has left
Ge0rGhas left
Guushas left
vanitasvitaehas left
blablahas left
blablahas joined
tuxhas joined
ralphmhas joined
Valerianhas left
tuxhas joined
rishiraj22has left
la|r|mahas left
Kevhas left
Guushas left
Guushas left
Martinhas left
Chobbeshas joined
vanitasvitaehas left
vanitasvitaehas left
vanitasvitaehas joined
blablahas joined
tuxhas joined
Guushas left
jubalhhas joined
Guushas left
vanitasvitaehas left
Guushas left
Guushas left
Guushas left
peterhas joined
Nekithas left
Guushas left
Guushas left
Nekithas joined
vanitasvitaehas left
Yagizahas joined
jubalhhas left
Chobbeshas joined
SyndaceSo, I collected the OMEMO issues that I was able to filter from the short discussion earlier and wrote down my thoughts and ideas about them: https://hackmd.io/x70DAtLgSHqBzke49_vBrg
I'd like to hear whether I grasped the core of the issues and whether my thoughts/ideas make any sense lol.
Also please tell me what's missing and feel free to add your own ideas and comments.
Dave CridlandSyndace, Are you aware of the MLS work under way in the IETF?
jubalhhas left
SyndaceOh boy, I was not
MattJDave Cridland, I'm assuming you are following it because you keep talking about it. How far is it from something everyone can implement?
Guushas left
mrdoctorwhohas joined
Valerianhas joined
Guushas left
goffiSyndace: we can't send some data becose there is not full stanza encryption. I'm specially missing xml:lang like I've explained on the @standard list (and some other like message markup).
jonaswSyndace, section 1, Idea #2 seems waaaay too complex
Guushas left
Syndacejonasw, well but I think it would fix all issues at once
Dave CridlandMattJ, Early days. But it's got some serious people working on it. You can actually get libraries and work with the current design, but it's approximately as scary as using TLS 1.3 draft 3 - chances of everything interopping in the future are pretty low.
jonaswat the cost of UX, Syndace
Guushas left
Dave CridlandMattJ, I'm not saying we should switch now. I'm just saying we should be prepared to write off OMEMO as an experiment in a year or so.
Syndacejonasw: True
SyndaceDave Cridland: Well great.
jonaswsolving bad UX by making it worse doesn’t seem good to me :)
Syndacejonasw: Not worse I think
MattJDave Cridland, I don't think that's a reason to not attempt to fix problems we have today in parallel
Guushas left
MattJIf MLS is ready in a year, it's another 2-3 years before clients implement it widely enough
Syndacejonasw: Do you think it's a super UX killer if you have to select which devices you want to exchange encrypted data with?
MattJmeanwhile OMEMO is already quite popular today, even Pidgin supports it
Dave CridlandMattJ, Well, I think we have an opportunity to show XMPP can be leading edge in this kind of thing.
MattJSure, I'm up for that
MattJBut the carousel of E2EE solutions is also a bit of a joke by now
jonaswSyndace, yes, other systems have E2EE without such annoyinaces
Dave CridlandMattJ, Yes, indeed.
jonaswMattJ, no, pidgin *does not* support it.
MattJLet's not leave what we have working today at 90% for the next 1-3 years
jonaswpidgin has two plugins both of which have their own quirks
jonaswand it doesn’t even "have" those plugins as in they’re distributed, no, you have to get them from somewhere.
MattJjonasw, that worked against my argument, so I glossed over that (but yeah)
jonaswDave Cridland, MattJ, if we’re going to do another round in the E2EE protocol carousel (good term by the way), I’d suggest to tackle (nearly) full stanza encryption, to at least give it a benefit over staying with status quo
Syndacejonasw: Is there a comparable system which allows multi-device e2ee where some devices do e2ee and some don't?
tahas joined
jonaswSyndace, I don’t know, actually. but users won’t care about that
jonaswin the end, you can have signal/whatsapp/whatever on botth your laptop and your phone and it works just fine -- even if on your laptop, you just view stuff which is on your phone via webrtc or something
jonaswand competing against that with a complex selection dialog whenever you want to do e2ee, just nope
kasper.dementhas joined
Guushas left
jubalhhas joined
Syndacejonasw: We could reduce it to "start private chat" which just starts the chat with all OMEMO-enabled devices and doesn't ask which devices should be included
SyndaceThat way it would be a button click
jonaswSyndace, and then we’re exactly where we are right now
MattJbut not by default
Dave Cridlandjonasw, Sure. But given MLS also handles group chat (in fact, it *doesn't* handle anything but), that shoudl also provide impetus.
jonaswDave Cridland, OMEMO handles group chat today
Syndacejonasw: Not really, because it's two seperate chats: One plaintext and one encrypted and the important thing: The user is aware that not all devices will get all messages
goffijonasw: is there a spec for that?
Dave Cridlandjonasw, Sort of. It handles groupchats by keying M times. MLS does it in one.
jonaswgoffi, dunno
jonaswDave Cridland, sorry, I have no idea
jonaswI just know that it is possible
Guushas left
Dave Cridlandgoffi, Good grief no. Did you think OMEMO was one of those *open* standards?
goffiI know Conversation and Gajim handle it, but I think it's unofficial for now (i.e. no XEP)
jonaswSyndace, "but other systems do have e2ee by default, why can’t you?"
lovetoxhas joined
Guushas left
Syndacejonasw: Because we don't forve you to use it. You can though, by clicking this button right here
Zashe2ee as an afterthought is going to be infinite pain whatever way you do it
MattJgoffi, I'm not sure a spec is really needed
jonaswSyndace, that doesn’t need any additional magic though. just *some* clients stepping back from the "OMEMO by default and everywhere" paradigm
MattJgoffi, it's just MUC, you fetch the keys of all participants
Guushas left
Syndacegoffi, I think they just parse the MUC-style JID into the normal JID and then use OMEMO as usual
Guushas left
jonaswZash, WhatsApp supposedly managed to do it as an afterthought
goffiGajim told me last time I was in a MUC for testing, that it was working with member only rooms something like that (don't remember the message)
Syndacejonasw: WhatsApp has one binary and forces usage of e2ee, would be easy with these preconditions
goffithis should be explained in a XEP, even if it's short
Syndace(or three binaries for each OS, whatever)
Guushas left
Zashjonasw: supposedly. also they're one company who do all the clients
waqashas joined
Guushas left
Dave CridlandI suspect we'll need an HSTS equivalent for E2EE, certainly, and then move plaintext->opportunistic->e2ee-always
Zashif clients were registered and known by the server then maybe
goffiwe are still blocking a bunch of XEP with OMEMO by default
Guushas left
goffias long as there is no full stanza encryption
Guushas left
Dave CridlandZash, I suspect client registration has ot become a Thing, anyway. There's a whole lot of optimizations we could do if we had that.
Guushas left
goffino more last message correction, no more in band real time text, no more, no more language detection, no more markup.
Zashgoffi: but we have the markdown-ish thing now /s
jonaswgoffi, but markup is in the <body/> nowadays anyways!!
Guushas left
Dave Cridlandgoffi, Honestly, you needn't argue for full-stanza. ESessions had that a decade ago, I have no idea why OMEMO doesn't.
Zashjonasw^5
goffiZash: don't tell me :'(
jonaswDave Cridland, possibly because time-to-market mattered more than doing things right?
jonaswZash, ^5
Dave Cridlandjonasw, Probably.
jonaswDave Cridland, I’d love if we could maybe not repeat the same mistake with whatever MLS integration will happen.
Dave Cridlandjonasw, Yes. I'd like to do that one right.
vanitasvitaehas left
SyndaceAny info on how/whether MLS handles mixed plaintext-only clients and encrypting clients?
jonaswDave Cridland, Zash, if it ever gets less hot so I can think straight for more than 5 minutes in a row, I’m going to try to make some device identification thing in prosody. I need per-device passwords anyways.
Dave Cridlandhas left
SyndaceIf we had device identification we could issue a simple warning: "If you send this message encrypted, only jid: phone and jid: laptop can receive the message. jid: web and jid: work can not."
goffiI would argue that I rather use OX by default, I'm less interested in PFS that in mentioned features.
Zashjonasw: I hear MattJ was working on that
goffiand OX do full stanza encryption.
MattJjonasw, er, yeah, I have a mod_device_tracker
MattJI can publish it later today or tomorrow
jonaswMattJ, I’m thinking about doing things in SASL
pep.MattJ: tracker!! I knew it
MattJpep., it's ok, it asks for consent
Zashjonasw: FWIW you could have per-device usernames too (or username+device), since they need have no relation to the bound JID
jonaswZash, I was more thinking of using the second identity one can pass in sasl
jonaswif it’s a full JID with the bare JID equal to the one you’re authing for, the resource is the device ID
Zashjonasw: modulo client support
jonaswZash, yeah...
jonaswbut do clients support getting forced to a different bare JID?
ZashSure
jonaswI need to have tests for that.
jonaswI’m not sure what aioxmpp would do
Zash+1
ZashMoar tests :)
jonaswZash, fun fact, I’ll probably go for device@username for per-device-passwords in IMAP :)
Dave Cridlandjonasw, See https://tools.ietf.org/html/draft-cridland-kitten-clientkey-00
Zashjonasw: Have you noticed the client-uses-full-bind-something pidgin sends in the stream start?
jonaswZash, no
Zashjonasw: Which had something to do with GTalk
jonaswDave Cridland, in my scenario, the devices would never learn the actual account password
jonaswwhich is something I’d like to have
jonaswactually, this is uspposed to be client certificates lite
jonaswbecause client certs are hard
vanitasvitaehas left
ZashIt could assign you a different hostname even, if you had whatever the hosted domain thing was
jonaswZash, crazy stuff
jonaswneed to keep that in mind; that might be useful to have to support legacy clients
Zashsure
ZashThere are some modules in Prosody where the SASL username ends up differently from the JID localpart
jonaswinteresting
ZashSome PHP forum one for example
ZashOne where you can have characters in the username that don't pass nodeprep
Dave Cridlandjonasw, Do a PIN-check on another session? But anyway, I'm happy to knock around idea on that with you.
jonaswDave Cridland, sounds good, but as I said .... it’s too hot here to think
tahas joined
jonaswDave Cridland, my idea was somewhat like this:
- to add a new device, you generate an auth-code on your first device and enter that in the new device. it performs either something SASL2 or a variant of IBR to set a password for itself (the password is never shown to the user)
- it will always authenticate with that password (somewhat like your CLIENT-KEY I suppose)
- server can now track the device, which also means that a user can revoke any device at any time (e.g. lost or stolen)
Valerianhas left
jonaswDave Cridland, IIRC, client key had the issue that when the counter goes out-of-sync, you need to re-authenticate using the normal SASL mechanisms?
alacerhas left
alacerhas joined
Dave Cridlandjonasw, Yes. It's designed as a "Remember this device" to go along with TOTP, and not exactly wehat you're after.
jonaswmmmhm
Martinhas left
Dave Cridlandjonasw, But that counter is intentional - anyone stealing the credential from the client cannot use it from another device if the original device is still in use - the counter gets out of sync and the server-side token is killed.
jonaswI think CLIENT KEY is orthogonal to this, yeah. It could be used in a, as you say, "Remember this device" fashion to temporarily replace the SCRAM-with-device-password+TOTP flow if TOTP is used,.
Chobbeshas joined
jonaswDave Cridland, yupp, that’s good
Dave Cridlandjonasw, Oh, and it's designed such that you can't DoS the token by guesswork or stealing it from the server.
muppethhas joined
muppethhas joined
jonaswit looked pretty solid when I looked at it back then, yeah
jonaswbut IANAC
404.cityhas joined
Dave CridlandC = Cryptographer?
jonaswyes
Dave CridlandNor am I, but I play one on TV.
jonasw:D
Valerianhas joined
Chobbeshas joined
danielhas left
pep.has joined
alacerhas left
vanitasvitaehas left
muppethhas joined
Guushas left
Guushas left
pep.Syndace: in your pad, section 4 before idea1, you are confusing omemo and e2ee. e2ee doesn't require PFS
vanitasvitaehas left
jubalhhas joined
Martinhas left
vanitasvitaehas left
vanitasvitaehas left
Martinhas left
Syndacepep.: Right.
danielhas joined
Guushas left
Guushas left
jonaswpeople suggesting:
> In general, a short “yo, please deactivate OMEMO” plaintext answer should be enough. But this can be annoying if it happens too often!
clearly have no idea at which level of technological literacy some people operate
pep.Indeed
jonaswSyndace, append to your list please "I re-installed Conversations and now I can’t access my history anymore", because people aren’t expecting PFS.
Syndacejonasw: lol, yes I know that some people don't know what OMEMO is and how to disable it, come on don't take this so literal :D
pep.Syndace: this is a real world issue :x
nycohas left
labdsfhas joined
Syndacejonasw: Better example of what to write?
Guushas left
Andrew NenakhovOur take on encrypted conversations that we plan to implement soon is to have separate encrypted and decrypted chats. Like telegram's secret chats.
Guushas left
vanitasvitaeSyndace: after having implemented OX (OpenPGP for XMPP) I think one huge improvement that OX is having over OMEMO is the ability to encrypt arbitrary extension elements. I think full stanza encryption is rather unrealistic for xmpp, but you can put all the sensitive data into an encrypted container and be done :)
vanitasvitaeWe should really port this to OMEMO / put it in a standalone XEP and let OX and OMEMO depend on it
Andrew NenakhovTelegram also solves multidevice e2ee quite simply: secret chats are one on one device only.
SyndaceAndrew Nenakhov: Interesting, who is "our"?
Andrew NenakhovXabber.
vanitasvitaeAndrew Nenakhov: the single device part is one of the things that keep me from using secret chats :/
Guushas left
Guushas left
Andrew NenakhovI also hate pfs obsession
Valerianhas left
lovetoxnobody has a pfs obsession
lovetoxits just what we have
Andrew NenakhovPublish a pgp key, share it to all devices, have your history everywhere.
vanitasvitaeMoxie does :D
lovetoxwe cant just snip our fingers and invent super secure encryption protocols
lovetoxAndrew Nenakhov, yes you can do that with OX
Andrew NenakhovIf you care that much about privacy, don't lose that key.
lovetoxOmemo was just there first, and its easier to implement
Andrew Nenakhov> Moxie does :D
A lot of other guys do too. Constantly bombard our issue trackers with demands.
vanitasvitae:D I have heard of that infamous bug report ;)
SyndaceWhat about a mechanism to synchronize local history from another device? xD
Andrew Nenakhov:-D
Andrew NenakhovThat bug report is, yes, epic
blablahas joined
MattJSyndace, that has been discussed in the past - the protocol is already there - XEP-0313 could work between clients just as it does between client and server
Zashhas left
Andrew NenakhovBtw, why would people want "full stanza encryption"?
Zashhas joined
Andrew NenakhovIf you encrypt whom you address stanza, it'll never be delivered 😂
rishiraj22has left
vanitasvitaeAt FOSDEM I heard the idea of establishing encrypted XML streams between clients :D
lovetoxobviously not the top element..
MattJvanitasvitae, that has also been discussed and done before
Steve Killehas left
Steve Killehas left
labdsfMattJ: gajim recently removed this feature
SyndaceMattJ: Wondering how serious to take this idea
Andrew NenakhovWhat is there to encrypt besides top element 😂😂😂
lovetoxevery child element?
SyndaceWould be pretty cool to have history even on fresh OMEMO devices
MattJAndrew Nenakhov, OOB element for file transfers, for example
labdsfhas left
labdsfhas joined
Andrew Nenakhov> Would be pretty cool to have history even on fresh OMEMO devices
As I understand OMEMO, this wish goes against all it stands for. :-/
SyndaceNot if you can sync the local history from your other devices or your chat partners
labdsfAndrew Nenakhov: Signal has synchronization between start vices
labdsfBetween devices*
lovetoxit can provide this, because it does not have to deal with different clients
Syndacelovetox: Doesn't sound very hard to throw the serialized XML into OMEMO instead of a plaintext message for nearly-full-stanza-encryption
lovetoxthis would mean making a protocol for exchanging databases
Steve Killehas joined
lovetoxwho said full stanza encryption is hard? as some people point out this exists probably for a decade in xmpp
SyndaceWhat about substanzas that are meant for the server (like hints)?
lovetoxyou obviously cant encrypt them because then they are useless
SyndaceI was wondering whether to treat them in a special way or to just ignore them
lovetoxwith full stanza encryption we dont mean full like everything
lovetoxwe mean all data that are not necessary for the server to function
Guushas left
nycohas left
Andrew Nenakhov> Andrew Nenakhov: Signal has synchronization between start vices
Doing that is definitely possible in a number of ways, every single of them denying all advantages their protocol has over PGP.
Andrew NenakhovYou can sync history directly between devices. You can share keys and download and decipher messages from server archive
Andrew NenakhovBut why bother using omemo if you plan to do that?
404.cityhas left
Syndacesignal uses omemo aswell (basically)
Syndacewhy do you think they do it that way? because its convenient probably
vanitasvitaeIf you do the backup exchange using OMEMO, you dont lose any advantages of OMEMO
jjrhhas left
vanitasvitaeif you do it via OpenPGP however, your whole history is on the server twice, once OMEMO encrypted and once via OpenPGP. In that case you lost pfs due to the OpenPGP copy which can in theory be decrypted in the future.
jjrhhas left
vanitasvitaeSo for backup exchange you'd want to generate a single-use key.
Andrew NenakhovWhy twice? One openpgp is enough.
Andrew NenakhovBackup exchange is also bad ux by the way.
Andrew NenakhovYou want your messages everywhere at once.
Andrew NenakhovSo in the end if you want security and convenience , just run your own server.
vanitasvitaeThen you need OpenPGP and you cannot have pfs
Andrew NenakhovBecause in xmpp the only ones who are affected by e2ee are server operators.
jjrhhas left
goffiho Gajim removed direct stream encryption? What a pity, I find it the most secure way if you have something really sensitive to say
goffiI guess same effect can be achieved with XEP-0396 nowaday
Guushas left
lovetoxGajim never head direct stream encryption
Guushas left
lovetoxand why is it a pity if no client supported that?
Dave Cridlandhas left
Guushas left
doshas left
labdsfhas left
moparisthebesthas joined
moparisthebesthas joined
Link MauveHi, what should happen with MAM when a client did a <query/> without specifying a @queryid? Should the <result/>s also not contain one?
Link MauveSo far I made it required in my parser but I guess it should be optional due to that.
lovetoxyes Link Mauve correct
lovetoxdont add a query element if the client doesnt set one
lovetoxmakes no sense, because its a identifier for the client
lovetoxif it set none it doesnt need it
Link MauveYup.
Guushas left
Guushas left
karphas left
karphas joined
Alexhas left
Guushas left
kasper.dementhas joined
Link MauveWut, the changelog of RSM says that the <index/> element has been removed, but it is still present thrice in the text (including twice in examples).
jonaswmaybe a different <index/> element? *hope*
flowLink Mauve, attribute vs element?
Link MauveNope, I checked already.
Link Mauveflow, nope.
flowahh right, the elemnt still appears in the text
Link MauveHmm, I think I should split my RSM element into query and result, that would make it a lot easier to understand what’s going on.
flowWho is 'vm'?
Link MauveSomeone from before my time, I guess.
rionhas left
kasper.dementhas joined
michaelhas joined
jonaswThis one just came up in another room: https://xmpp.org/extensions/xep-0238.html
jonaswdo we maybe want to deprecate/obsolete/reject that?
jonaswit seems to be ... way out of date
jonaswand there doesn’t seem to be any interest in refining it
karphas left
karphas joined
michaelhas left
Chobbeshas joined
lskdjfhas joined
karphas left
karphas joined
alacerhas joined
Link Mauvejonasw, +1, although in the past we’ve considered deferred as a tombstone.
Link MauveBut I’m still +1 to explicitly obsolete it.
kasper.dementhas joined
jonaswyeah, deferred isn’t explicit enough
Link MauveAnd I think we shouldn’t let XEPs stay in limbo like that forever.
YagizaIf I implement deffered XEP in my software, may it change its status?
Link MauveYagiza, you should send an email to standards@ to explain why imo, then someone will most likely revisit it.
ZashYagiza: Possibly, especially if you write to the standards@ list or the author with feedback
jonaswYagiza, there are two types of deferred XEPs (and you cannot tell them apart by the status): those which are abandoned, and those which are "good enough" and which are silently implemented everywhere
jonaswYagiza, so if you implement a deferred XEP, post any feedback you have to standards@ (even if it’s just "implemented it, it solves my issue X"), that might trigger advancement to Draft
Link MauveYou may also send a change, anything, something you found missing/misformulated/anything in the text, which would automatically put it back to Experimental.
Zashjonasw: I'd say there's some gray area inbetween, where the author just happens to be busy with other stuff
jonaswZash, I’d call that "abandoned", even though that’s harsh
Link MauveZash, can confirm. :-°
404.cityhas joined
Zashjonasw: sounds intentional then, which it might not be
jonaswhm, ok
YagizaI just want to try implementing XEP-0371 in my client as a good solution for file transfer.
jonaswYagiza, uh... in combination with XEP-0234?
Alexhas left
YagizaYes, of course
YagizaAlso, its implementation may increase chances of successful Jingle RTP session.
Link MauveThis one is an instance of the good kind of deferred XEP.
lorddavidiiihas joined
mikaelahas joined
Guushas left
muppethhas left
muppethhas joined
YagizaLink Mauve, so, if I implement it, it may make things better?
jonaswyes
YagizaOk. Sounds good.
karphas left
karphas joined
ZashHigher chance of things becoming better if you send feedback to standards :)
waqashas left
karphas left
karphas joined
karphas left
karphas joined
Alexhas joined
doshas joined
Link MauveIn pubsub#event, I see @node being defined on item, but I don’t see it used anywhere in the XEP.
Link MauveWhat and where could it be used for?
Alexhas joined
ZashSection?
Link MauveXML Schema.
Zashhttps://xmpp.org/extensions/xep-0060.html#example-2 that @node ?
Dave Cridlandhas left
Link MauveThis is on items, not on item.
mrdoctorwhohas joined
Dave Cridlandhas left
ZashWait where do you see a node attr?
Link MauveLine 7007 of the XML file in the xeps repository.
Link MauveOh no, this is commented in the XML file.
Zashhas left
jonaswLink Mauve, where?
jonaswah nevermind
Guushas left
Guushas left
Guushas left
Guushas left
Link MauveIs it actually possible to have a <{pubsub#event}items/> with neither <item/>s nor <retract/>s inside?
YagizaZash, that's implied
pep.has left
lskdjfhas left
lskdjfhas left
karphas left
karphas joined
Guushas left
marchas left
Guushas left
Zashhas left
karphas left
karphas joined
Zashhas joined
marchas joined
lskdjfhas joined
Zashhas left
labdsfhas joined
jubalhhas joined
jubalhhas left
lskdjfhas left
karphas left
karphas joined
lskdjfhas left
lskdjfhas left
lskdjfhas joined
lskdjfhas left
karphas left
lskdjfhas left
karphas joined
lskdjfhas joined
SamWhitedhas left
doshas left
Dave Cridlandhas left
lumihas left
lskdjfhas joined
rishiraj22has left
karphas left
karphas joined
Yagizahas left
kasper.dementhas joined
kasper.dementhas joined
labdsfhas left
labdsfhas joined
rishiraj22has left
lskdjfhas left
lskdjfhas left
karphas left
karphas joined
karphas left
karphas joined
kasper.dementhas left
lskdjfhas left
kasper.dementhas joined
goffihas left
lskdjfhas joined
lskdjfhas joined
lskdjfhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
lskdjfhas joined
lskdjfhas joined
valohas left
jubalhhas joined
valohas joined
kasper.dementhas left
karphas left
karphas joined
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
valohas left
lskdjfhas joined
kasper.dementhas joined
lskdjfhas joined
lskdjfhas left
lskdjfhas left
jerehas left
j.rhas joined
valohas joined
kasper.dementhas left
lskdjfhas left
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
karphas left
karphas joined
Dave Cridlandhas left
Dave Cridlandhas joined
kasper.dementhas joined
doshas joined
Dave Cridlandhas left
Dave Cridlandhas joined
lskdjfhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
jerehas joined
lumihas joined
Chobbeshas joined
j.rhas joined
j.rhas joined
remkohas left
karphas left
karphas joined
kasper.dementhas joined
karphas left
karphas joined
karphas left
karphas joined
marchas left
marchas joined
jubalhhas joined
kasper.dementhas joined
Link Mauve“19:09:00 vanitasvitae> At FOSDEM I heard the idea of establishing encrypted XML streams between clients :D”, yes, XEP-0246, XEP-0247 and XTLS. ^^
vanitasvitaeLink Mauve: yeah I think we talked about it right?