grumpyHi Ge0rG et al. I was talking with moparisthebest in chat@dino.im?join about "XEP-0283: Moved". Since there doesn't seem to be a solution yet to the problem, how to migrate an account *after* the original server already shut down, I wrote a short proposal on that: hhttps://paste.dismail.de/?4c1fbdcfe545a21f#+Coc2+h/McMVvg4/qtzCeChc8QQ03yBQVOotnZTZrIc=
jonas’haha I like the title
grumpyEven if it might have some glitches and you maybe want to put it more XMLish as I did, I hope it helps and if its even only to put the discussion further. ;)
j.rhas joined
jonas’grumpy, hm, what’s the purpose of the server key?
grumpyto sign, that I had an account on that server.
jonas’ah, right, so that a client can’t claim a random account
rtq3has joined
grumpyYes.
jonas’this looks sound on the first glance
jonas’it requires upgrades to all involved servers though
jonas’and of course it’s a cryptoscheme so it needs hard thinking to ensure that it’s right
grumpySure.
Alexhas joined
grumpyMaybe it could be even possible without the server key, if we use the trust from the already established subscription. But then the client somehow needs to publish it's public key beforehand.
grumpyThe main idea is that each server has the possibility of validation even after the origin server went off the wire.
jonas’grumpy, the public key could be published for example in a PEP node
jonas’I think this is along the lines of what pep. had thought of
grumpySounds good. Then every subscriber needs to cache the keys for its subscriptions. And if they went off they can be reestablished. Should it be really that easy? That would be cool. :)
j.rhas joined
olihas joined
wurstsalathas joined
wurstsalathas joined
Ge0rGgrumpy: that's an adorable idea, and it introduces a cryptographic overlay network on top of xmpp, which is very similar to, but not equal with OMEMO.
vaulorhas joined
Ge0rGAlso it requires support from all involved entities, and it depends on client identities
pep.Ge0rG: depending on what guarantees you want I think you won't have much choice about the crypto
rtq3has left
rtq3has joined
Guushas left
lnjhas left
Guushas joined
lorddavidiiihas left
Half-ShotXhas left
Half-ShotXhas joined
flowhas left
labdsfhas joined
Zashhas left
Zashhas joined
pep.One thing I'm annoyed at and I don't know what to do about is evil servers. Do we want to worry about that, what if that's the reason for a move in the first place.
pep.I know the usual criticism about thinking they could even be such a thing as an evil server and I get it because I've got my own as well, but most users don't, and that's why the crypto hype.
pep.Lots of assumptions break once you include that in the addition..
jonas’pep., if the server is evil, what stops them from just not signing your tokens at all? or preventing you from sending your signed tokens to other parties?
jonas’preventing you from publishing the key?
pep.jonas’: yes, this proposal doesn't work at all if evil is in the game
pep.Otherwise I think it's nice. There are still a few things to fix I think
jonas’pep., I don’t think any proposal can work with a reasonably evil server, unless we go true peer-to-peer, which has its own mess; since you can’t trust your server, you’d need a separate directory service or whatever to find a way to connect to your peer, at which point we’re not doing XMPP anymore.
pep.Depends what you want to call XMPP :)
Ge0rGWhat about making Moved depend on a signed OMEMO message with the old JID in the meta data?
andyhas joined
pep.Ge0rG: I assume sarcasm?
Ge0rGpep.: no. AMIGO attempts to establish a new crypto identity on top of xmpp, which doesn't need to be intertwined with xmpp in any way. The *essential* piece of info is "look, you know this cryptographic key belongs to me (device or user), and I'm proving to you now that I'm still me with this new JID"
pep.Yeah I get that, and I see the pattern
pep.It's just funny coming from you now :p
Ge0rGpep.: it would work the same with OX or any other mechanism where you established trust before server shutdown
jjrhhas left
pep.Yep
jonas’OTR!
jjrhhas joined
pep.I was thinking about abstracting the crypto from this tbh
Ge0rGIt's counter productive to implement a new crypto scheme just for this
pep.You can just plug in anything that'll prove your identity
Ge0rGpep.: In that case all you need is a `<moved from=oldJID>` plus some hand waving about cryptographic signatures
remkohas joined
moparisthebesthas joined
Ge0rGpep.: so essentially just an implementation note on Moved
Ge0rGAs long as it doesn't end up just comparing OMEMO fingerprints, I'm okay with it being used.
lnjhas joined
rtq3has left
rtq3has joined
Ge0rGObviously, I'd love to have an E2EE scheme that only uses a single per account x25519 key, which can be simply synchronized between devices to give access to MAM, but people need to fap over PFS, deniability and other theoretical benefits while storing their clear logs of their comms into unencrypted SQLite...
grumpypep.: I suppose the main reason for moved is mostly bad maintained servers, not necessarily evil ones. Since to my experience onboarding and getting an account (especially where?) is (excluding Quicksy) still the biggest problem for the average users. It's very likely that they pick that one which goes offline tomorrow. :) Therefore I would like to see moved supporting migration *afterwards*.
Ge0rGThe most sophisticated part would be a phrase / QR based challenge response handshake to establish mutual trust between two devices (your own or your friend's), to exchange keys on the wire
Ge0rGgrumpy: you won't get the server parts of AMIGO implemented on unmaintained servers
Ge0rGgrumpy: the best thing you can do is to establish a cryptographic identity by sending messages from the old server while it's still up.
Ge0rGgrumpy: and if your friend's client supports AMIGO, it can just cache your fingerprint and accept a JID update from anyone asserting that same identity
grumpy> jonas’: pep., if the server is evil, what stops them from just not signing your tokens at all? or preventing you from sending your signed tokens to other parties?
With the workflow I proposed the user could even recognize that. If the server doesn't sign or gives a wrong signature, you could check against the servers public-key.
All other interaction jsut depends on your client and the new server accepting that.
grumpy> Ge0rG: grumpy: you won't get the server parts of AMIGO implemented on unmaintained servers
Thats good. Because that fact could be exposed to the user and the client could remind maybe *not* to choose a server *not* supporting moves. ;)
Ge0rGgrumpy: there is really no need to depend on anything from the old server except for sending messages or maybe PEP
waqashas left
grumpyYa, PEP sounds like the right way to do so.
Ge0rGgrumpy: you are answering to the least important parts of what I said... 😉
grumpy> Ge0rG: grumpy: and if your friend's client supports AMIGO, it can just cache your fingerprint and accept a JID update from anyone asserting that same identity
That is IMO the most important one.
grumpy:)
Ge0rGgrumpy: yes
jonas’grumpy,
> Thats good. Because that fact could be exposed to the user and the client could remind maybe *not* to choose a server *not* supporting moves.
That doesn’t help the users which are already on such a server.
Ge0rGgrumpy:
> pep.: it would work the same with OX or any other mechanism where you established trust before server shutdown
> It's counter productive to implement a new crypto scheme just for this
pep. [09:22]:
> You can just plug in anything that'll prove your identity
grumpy> jonas’: That doesn’t help the users which are already on such a server.
Sadly true.
Ge0rGNow that I've wrote the sentence about x25519, I have a feeling I need to write it down and implement it, just to prove a point
404.cityhas left
rtq3has left
rtq3has joined
grumpyGe0rG: I would guess that a lot of people would like it because of having working MAM again. :)
Ge0rGAlso the whole implementation would be something like 100 LoC
jonas’how’d you do the sync?
Ge0rGBut it wouldn't appeal to cryptowhores, who are the main promotion group for XMPP
Ge0rGjonas’: what sync?
grumpysync the keys between devices, i suppose.
jonas’what grumpy says
Ge0rG> The most sophisticated part would be a phrase / QR based challenge response handshake to establish mutual trust between two devices (your own or your friend's), to exchange keys on the wire
goffihas joined
jonas’yeah
olihas joined
Zashhas left
mimi89999has joined
rionhas left
pep."grumpy> Thats good. Because that fact could be exposed to the user and the client could remind maybe *not* to choose a server *not* supporting moves. ;)" < So you're not considering existing accounts?
pep.Oh jonas’ already pointed that out
Alexhas left
pep.Ge0rG, please do
rtq3has left
rtq3has joined
Ge0rGand the libsodium.so should be <200KB
grumpypep.: Yes, and I of course agree that existing accounts should be taken into consideration too. I was just overwhelmed by the idea that clients could give the users a useful recommendation for selecting a server. :)
Ge0rG"useful recommendation" is a HARD problem. yax.im for example tries to strive a good balance between stable and required-but-beta features, and is the server with the best spam filtering. But the former means it's bad at "compliance" "benchmarks", and there is no automatic way to convey the latter. So from outside, it looks sucky.
grumpyI understand, but don't you think there are at least some things which could be taken into account, like longevity, s2s-availability, valid ssl-certs, support of some basic XEPs. currently users pick servers by names and... yeah thats it. :)
Ge0rGgrumpy: some of those things can't be usefully measured by a client
vaulorhas joined
MattJhas left
grumpyI was thinking of having a list somewhere at xmpp.org/net which client devolopers could pull at minumun at built time or at which online. That would contradict the spirit federation a bit, though.
grumpys/which/wish/
jonas’grumpy, you’re aware of this thing? https://compliance.conversations.im/
jonas’nice, browser in-page search doesn’t work there
Ge0rGjonas’: yeah. You can't search for a server domain.
Ge0rGAnd they are sorted by $random
grumpyI am of course. ☺ Does any client uses it? I use it manually for myself. And, even without looking, I would guess that yax.im does not have 100%, so would be unfair in Georgs POV. :)
jonas’it is on the seventh or so place
jonas’from below.
jonas’from the bottom.
Ge0rGgrumpy: it's not "unfair", it is just not providing the right criteria in my mind.
jonas’one would need a jury with lots of time on their hand to curate a list of servers
grumpyok, that's what i wanted to express.
Ge0rGit's like with xmpp.net - having an A+++ rating won't protect you from an asshole admin or a server that's more down than up
grumpyHmm..
grumpyI think at least a minimum like sort by uptime would help more than nothing. But we'll see.
pep.I did get join{xmpp,jabber}.{net,com,org} (expect jabberxmpp.org actually, for reasons, but I'll poke people), for this ^
jonas’jabberxmpp.org?
pep.oops
pep.joinxmpp.org
pep.I did get join{xmpp,jabber}.{net,com,org} (expect joinxmpp.org actually, for reasons, but I'll poke people), for this ^
Ge0rGgrumpy: there is also https://status.conversations.im/historical/
Ge0rG(yes, my ISP was down last night for half an hour or so)
Half-ShotXhas left
MattJI only just realised that the bookmarks XEP uses an unregistered URN prefix
ZashLegacy reasons
grumpyGe0rG: Also know, but unfortunately it's quite incomplete.
XSF Discussion - 2019-01-31