XSF Discussion - 2019-01-31

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=

haha I like the title

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. ;)

grumpy, hm, what’s the purpose of the server key?

to sign, that I had an account on that server.

ah, right, so that a client can’t claim a random account

Yes.

this looks sound on the first glance

it requires upgrades to all involved servers though

and of course it’s a cryptoscheme so it needs hard thinking to ensure that it’s right

Sure.

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.

The main idea is that each server has the possibility of validation even after the origin server went off the wire.

grumpy, the public key could be published for example in a PEP node

I think this is along the lines of what pep. had thought of

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. :)

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.

Also it requires support from all involved entities, and it depends on client identities

Ge0rG: depending on what guarantees you want I think you won't have much choice about the crypto

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.

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.

Lots of assumptions break once you include that in the addition..

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?

preventing you from publishing the key?

jonas’: yes, this proposal doesn't work at all if evil is in the game

Otherwise I think it's nice. There are still a few things to fix I think

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.

Depends what you want to call XMPP :)

What about making Moved depend on a signed OMEMO message with the old JID in the meta data?

Ge0rG: I assume sarcasm?

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"

Yeah I get that, and I see the pattern

It's just funny coming from you now :p

pep.: it would work the same with OX or any other mechanism where you established trust before server shutdown

Yep

OTR!

I was thinking about abstracting the crypto from this tbh

It's counter productive to implement a new crypto scheme just for this

You can just plug in anything that'll prove your identity

pep.: In that case all you need is a `<moved from=oldJID>` plus some hand waving about cryptographic signatures

pep.: so essentially just an implementation note on Moved

mmm, <signature xmlns="moved"><signed xmlns="...:eme:0" namespace="urn:xmpp:otr:0"/><signature-data>...</signature-data></signature>... ✏

As long as it doesn't end up just comparing OMEMO fingerprints, I'm okay with it being used.

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...

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*.

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

grumpy: you won't get the server parts of AMIGO implemented on unmaintained servers

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.

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

> 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.

‎> 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. ;)

grumpy: there is really no need to depend on anything from the old server except for sending messages or maybe PEP

Ya, PEP sounds like the right way to do so.

grumpy: you are answering to the least important parts of what I said... 😉

> 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: yes

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.

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

> jonas’‎: That doesn’t help the users which are already on such a server. Sadly true.

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

Ge0rG‎: I would guess that a lot of people would like it because of having working MAM again. :)

Also the whole implementation would be something like 100 LoC

how’d you do the sync?

But it wouldn't appeal to cryptowhores, who are the main promotion group for XMPP

jonas’: what sync?

sync the keys between devices, i suppose.

what grumpy says

> 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

yeah

"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?

Oh jonas’ already pointed that out

Ge0rG, please do

and the libsodium.so should be <200KB

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. :)

"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.

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. :)

s/s2s-availability/stable s2s-availability/ :)

grumpy: some of those things can't be usefully measured by a client

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.

s/which/wish/

grumpy, you’re aware of this thing? https://compliance.conversations.im/

nice, browser in-page search doesn’t work there

jonas’: yeah. You can't search for a server domain.

And they are sorted by $random

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. :)

it is on the seventh or so place

from the bottom. ✏

grumpy: it's not "unfair", it is just not providing the right criteria in my mind.

one would need a jury with lots of time on their hand to curate a list of servers

ok, that's what i wanted to express.

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

Hmm..

I think at least a minimum like sort by uptime would help more than nothing. But we'll see.

jabberxmpp.org?

oops

joinxmpp.org

I did get join{xmpp,jabber}.{net,com,org} (expect joinxmpp.org actually, for reasons, but I'll poke people), for this ^ ✏

grumpy: there is also https://status.conversations.im/historical/

(yes, my ISP was down last night for half an hour or so)

I only just realised that the bookmarks XEP uses an unregistered URN prefix

Legacy reasons

Ge0rG‎: Also know, but unfortunately it's quite incomplete.

Will looking forward on pep.'s site. :)

Bit late, but no Board Meeting today.

:)

Awwww..was so looking forward to it

Suuuuure

Hah