Modern XMPP project discussion - 2021-06-28

hello, we had a chat about account migration on another chan

i was proposing we should standardize client signatures for migration requests early on, whether clients wish to verify them or not

could use OMEMO or PGP keys you already trust as associated to an account, in my view

I think this goes well as an add-on XEP, especially since the different crypto-methods will have different ways to do that.

Sounds like one XEP that defines the wire format to be signed, ECAPS style, and a different XEP per encryption protocol for the signature.

Ge0rG, I was reminded more of jet

I think a choice of encryption protocols may be counterproductive

I think agility on that is required though

Sure

even if only to migrate from OMEMO -> whatever-follows-OMEMO

(without rewriting all the protocols)

But I'd prefer that someone chooses one way, specs that, and we can update it in the future if needed

and the issue of OMEMO having no key to authenticate the account (as opposed to the device) remains.

so OX would be the more natural choice for that

but "nobody" uses that

Who needs account keys anyway?!

Ge0rG, wasn’t SEX based on account keys?

Ge0rG, i was precisely proposing the mechanism to expose the signature be standardized as part of the XEP, then we can have extensions to describe how to achieve such signatures with this or that kind of keys

jonas’, SEX?

I see no advantage to that approach

MattJ, letting client devs know there are or is going to be signatures to valide the migration requests so they're less easily forged?

southerntofu: not the signature but the hash of the data to be signed?

jonas’: SEX was as sarcastic as my remark about account keys

southerntofu, and this is actionable for devs how? The spec already says further verification methods may exist in the future. Right now we can only guess how they may work.

Also I should say that my thoughts for crypto are not to protect from malicious servers, but to work around the scenario where the original server is no longer available

I see that as a common enough scenario that we should try to solve it if we can

#blabber.im

Indeed, and the many before it

duckduckgo, fastmail, ...

Both had XMPP services with thousands of users that they just decided to shut down

Neither actively wanted to prevent people migrating away

<new-jid>foo@bar</new-jid><signatures><SIG_TYPE>... defined in new extensions ...</SIG_TYPE></signatures>

maybe something like this?

where we agree `<new-jid>foo@bar</new-jid>` is what should be signed by the clients, but then the specific format can be further spceified

<omemo-sig xmlns="urn:xmpp:moved-omemo-sig:1">...defined in new extensions...</omemo-sig>

MattJ: shouldn't the OMEMO key be the primary identity of the user then, and the JID becomes a mere ephemeral routing token?

sure but maybe not just OMEMO though.. (i think PGP is very well suited for such cases)

Ge0rG, yes, sounds like a great plan.....

Ge0rG, yes precisely

<ox-sig xmlns="urn:xmpp:moved-ox-sig:1">...defined in new extension...</ox-sig>

i mean if you loose your keys you can still reestablish trust through other channels, but once you have keys exchanged it makes sense that keys are your identity

So now we have invented a cryptographic identity based overlay network on top of xmpp.

looks good

MattJ, do you think standardizing these OMEMO/OX extensions would be troublesome?

Now we can replace the server side roster with a client side list of trusted keys and their respective meta data and ephemeral JIDs, and we have a new secure chat system that has nothing to do with Jabber

southerntofu, not if you can figure out what to sign, how, with what key, and how recipients can verify it

Just do it

But there are no changes required to the current spec in this regard, it already allows for such extension, that's all I'm saying

ok i'll reread OMEMO spec :)

I don't consider myself a crypto person, but I see no way to reliably do this with OMEMO

There's already https://xmpp.org/extensions/xep-0415.html if we want P2P 🙂

> Libraries can use an Ed25519 key pair as their internal IdentityKey. In this case, the IdentityKey can create EdDSA-compatible signatures directly, and has to be converted first to perform X25519.

from OMEMO spec... sounds like OMEMO signatures are already well specified :)

southerntofu, I think the best way forward would be to write something down in XEP form

<editor-hat>I am happy to assist with any issues around the process</editor-hat>

thanks jonas’ i think i'll first try to craft a signature using my own OMEMO keys and verify it, just to see how it works

MattJ: If there is a way I can help with this let ne know https://xmpp.org/extensions/inbox/moved2.html

Thanks

MattJ, here's a PoC for signatures using OMEMO keys, using gajim keys https://tildegit.org/southerntofu/omemo-signatures

So how would it work? One of your devices signs the moved statement, and the recipients just check for any of their stored fingerprints for that user matching the signing key?

yes, the embedded signature(s) would also contain the corresponding public key, so if you have 10 keys for someone you don't have to try them all to find the correct one.. but that's the idea

Right

I guess this can also be implemented server-side... technically :)

sure thing

personally i find it more appropriate client-side so we can have a confirmation process before migrating, letting users know about it

but that's just a personal opinion :)

https://ttm.sh/FOS.txt <-- could look like this

also multiple signatures can be chained from different device keys

(the signature/key is bogus in this example i linked)

how would account migration handle existing message archives and published content on PubSub?

They are in the XEP-0227 file

Or they will be, when my update is approved and merged

yes i can see that, but the JIDs have changed, so if i query your microblog on your new address, even if data has been moved, the server will return nothing because the data is archived for your old JID... am i correct?

no because PEP is on the account, so it'll be imported to the new account

There should be no mention of a JID there I guess

pubsub though is different

Dunno how that's handled

If that's handled.

https://xmpp.org/extensions/xep-0277.html#example-2 <-- correct

at least when publishing there's no JID involved

yeah that's microblog, generally used on PEP (except Movim and Libervia use it on PubSub as well..)

And hmm, wait you're not quoting the appropriate block

https://github.com/xsf/xeps/pull/1064/files#diff-f94da706aed4fca9036ff0b2875918fe0a7021efbc004e76825e10c74463df0aR344

right well 227 doesn't mention pubsub at all does it

"out of scope"

PEP is part of MattJ pending update

Yeah

so consider me not nowledgeable about such things but very curious about changing JIDs and how that can break user expectations

But not generic PubSub data right. Though I guess that could easily be reused..

i expect migration to be "transparent" to me as an end-user so that i retain history and such.. maybe that was obvious idk :)

I sense some confusion.

I sense that some more "non-goals" should be added to Moved2 :P

If the data has been moved (= imported and exported) then it *would* be available at the new JID. Or why do you think not?

But that can be a problem for modernxmpp

Zash, that might be true of the person moving

Mechanisms for export and import are undefined as of yet, AFAIK, unless MattJ sneaked it into an update I haven't seen yet.

That won't be true of the contacts

Which leads to the Moved stuff magically creating that association.

And PEP stuff being presence based will magically start working again once you Moved all the roster relations.

Explicit (PEP) subscriptions can be passed through the export file ✏

Tbh, it feels like we don't have the same expectations. As much as I would like it to be, it doesn't seem to me XMPP is identity based atm, that is you'd have one identity that can stay the same whether you're foo@bar or baz@qxx.

(talking to southerntofu)

Things might go in this direction sometimes but I feel it's just a coincidence

I am absolutely not working on cryptographic identity for XMPP

Maybe someone can build that out of these blocks, possibly combined with others

To me that is a complex problem, while we have 5000 real users about to lose their XMPP accounts in less than a week

You honestly think you'd be able to migrate them in less than a week? :/

Well I had planned to work on jabber.org this week, but I hit a roadblock

So while I'm waiting I may as well try

Zash, i was/am concerned that some of that migrated data refers to specific JIDs and so i'm wondering if it would be possible or desirable to do something about that server-side so the move is transparent to the client

(which is not a question about cryptographic identity :))

but apparently at least for microblogging that's not a problem

MattJ, any way we / others can help with anything?

My current plan is to write a .ceb (Conversations/Blabber backup file format) -> XEP-0227 converter

Wait what

MattJ, did you see that Gajim (I think) import export work?

No

I think it was NIH'd XEP-0227 extensions

→ https://logs.xmpp.org/xsf/2020-12-27?p=h

Cross-MUC links when? ✏

as in sharing quotes between mucs?

or linking to a specific message in a muc?

Referencing specific messages in other MUC

Quotes optional

Zash, interesting conversation, shows there is interest for the question

Tho upon re-reading, this was exports from the client, not from the account/server.

Quite some overlap however, that would benefit from a shared format like XEP-0227

hm. entirely clientside implementation possible

wait, xmpp has message ids right?

if so, yes

if not, no

What is?

referencing specific messages

Matt, sounds like a plan, good luck with that.. i just took a look at BackupExportService in conversations and it looks hairy... doing a manual SQL export oO

It's possible

There's even XEPs for it IIRC

oh

Just, as always, client implementations 🙂

yet again, xmpp is held back by it's clients

Zash, yes it was about client interop, which is really good.. like you said if you don't have something like XEP-0227 then both c2c and s2s migrations are "impossible"

227 doesn't do anything about MUC affiliations etc. right?

xmpp:xsf@muc.xmpp.org?stanza-id=2020-12-27-f1637f8fabdf49c3 or something something

Not like it can

it's the same UX expectation, that one should be able to just swap client/server and everything should be more or less transparent

pep., nah, just bookmarks

So there's a bunch of channels you wouldn't be able to rejoin

category of things that would be easier if we had implemented MIX already

pep., probably MUC servers should also interpret the Moved request

It's not designed for them currently, but yeah maybe

Probably doable with some dance similar to what you'd do for presence subscriptions?

hmm, yeah maybe you can try to join the first time with a moved tag in it

MUC checks PEP and comes back to you

Might take some time though..

Magic registration-esque request?

Yeah, I think it needs something like that

But first things first...

pep., that makes sense to join with a Moved, but what if your old server has closed already by the time MUC server implements Moved?

That's not in the requirements for Moved2 :x

"First things fist, but not necessarily in that order"

So yeah..

pep., i'm not interesting in the requirements already defined or whether something should fit in this specific XEP or not, i'm interesting in the actual consequences in terms of UX and what we can do about it :P

It's not possible in this case, without cryptostuff

As you could have guessed

Then you need to teach MUCs OMEMO ><

You're gonna get some backlash I say :P

idk.. is there some kind of stanza for s2s announcements that can be archived server-side, so that when the server implements Moved it can retrospectively interpret Moved requests?

MUCs don't have to be link to any of your contacts' server

instead of making migration a synchronous process

Look at joinjabber.org

yes, but you didn't answer my question: is there a way with current default settings to have the MUC server save a Moved request for later processing? or would such requests be discarded because the server doesn't understand them?

like is there a special s2s namespace specifically for that kind of server requests that other servers may not understand yet but may wish to treat later?

Currently it would just discard anything it doesn't understand

That's what you do in XMPP

I don't think there is such a thing?

Otherwise it has to store stuff it doesn't know from strangers for... how long?

Sounds open to abuse

idk could be a per-server quota of like 1MB or something, or only accept such announcements from servers you already have trustworthy s2s relationships with, or..

but ok that's not an option unfortunately

MUC PEP? But it's not like you can publish on it yourself