-
grumpy
Hi 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
-
grumpy
Even 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. ;)
-
jonas’
grumpy, hm, what’s the purpose of the server key?
-
grumpy
to sign, that I had an account on that server.
-
jonas’
ah, right, so that a client can’t claim a random account
-
grumpy
Yes.
-
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
-
grumpy
Sure.
-
grumpy
Maybe 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.
-
grumpy
The 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
-
grumpy
Sounds 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. :)
-
Ge0rG
grumpy: 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.
-
Ge0rG
Also 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
-
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 :)
-
Ge0rG
What about making Moved depend on a signed OMEMO message with the old JID in the meta data?
-
pep.
Ge0rG: I assume sarcasm?
-
Ge0rG
pep.: 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
-
Ge0rG
pep.: it would work the same with OX or any other mechanism where you established trust before server shutdown
-
pep.
Yep
-
jonas’
OTR!
-
pep.
I was thinking about abstracting the crypto from this tbh
-
Ge0rG
It's counter productive to implement a new crypto scheme just for this
-
pep.
You can just plug in anything that'll prove your identity
-
Ge0rG
pep.: In that case all you need is a `<moved from=oldJID>` plus some hand waving about cryptographic signatures
-
Ge0rG
pep.: so essentially just an implementation note on Moved
-
jonas’
mmm, <signature xmlns="moved"><signed xmlns=":eme:0" namespace="urn:xmpp:otr:0"/><signature-data>...</signature-data></signature>...✎ -
jonas’
mmm, <signature xmlns="moved"><signed xmlns="...:eme:0" namespace="urn:xmpp:otr:0"/><signature-data>...</signature-data></signature>... ✏
-
Ge0rG
As long as it doesn't end up just comparing OMEMO fingerprints, I'm okay with it being used.
-
Ge0rG
Obviously, 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...
-
grumpy
pep.: 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*.
-
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
-
Ge0rG
grumpy: you won't get the server parts of AMIGO implemented on unmaintained servers
-
Ge0rG
grumpy: the best thing you can do is to establish a cryptographic identity by sending messages from the old server while it's still up.
-
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
-
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. ;)
-
Ge0rG
grumpy: there is really no need to depend on anything from the old server except for sending messages or maybe PEP
-
grumpy
Ya, PEP sounds like the right way to do so.
-
Ge0rG
grumpy: 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
:)
-
Ge0rG
grumpy: 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.
-
Ge0rG
grumpy: > 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.
-
Ge0rG
Now 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
-
grumpy
Ge0rG: I would guess that a lot of people would like it because of having working MAM again. :)
-
Ge0rG
Also the whole implementation would be something like 100 LoC
-
jonas’
how’d you do the sync?
-
Ge0rG
But it wouldn't appeal to cryptowhores, who are the main promotion group for XMPP
-
Ge0rG
jonas’: what sync?
-
grumpy
sync 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
-
jonas’
yeah
-
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
-
pep.
Ge0rG, please do
-
Ge0rG
and the libsodium.so should be <200KB
-
grumpy
pep.: 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.
-
grumpy
I 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. :)
-
grumpy
s/s2s-availability/stable s2s-availability/ :)
-
Ge0rG
grumpy: some of those things can't be usefully measured by a client
-
grumpy
I 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.
-
grumpy
s/which/wish/
-
jonas’
grumpy, you’re aware of this thing? https://compliance.conversations.im/
-
jonas’
nice, browser in-page search doesn’t work there
-
Ge0rG
jonas’: yeah. You can't search for a server domain.
-
Ge0rG
And they are sorted by $random
-
grumpy
I 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. ✏
-
Ge0rG
grumpy: 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
-
grumpy
ok, that's what i wanted to express.
-
Ge0rG
it'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
-
grumpy
Hmm..
-
grumpy
I 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 ^ ✏
-
Ge0rG
grumpy: there is also https://status.conversations.im/historical/
-
Ge0rG
(yes, my ISP was down last night for half an hour or so)
-
MattJ
I only just realised that the bookmarks XEP uses an unregistered URN prefix
-
Zash
Legacy reasons
-
grumpy
Ge0rG: Also know, but unfortunately it's quite incomplete.
-
grumpy
Will looking forward on pep.'s site. :)
-
ralphm
Bit late, but no Board Meeting today.
-
MattJ
:)
-
Tobias
Awwww..was so looking forward to it
-
ralphm
Suuuuure
-
Seve
Hah