[Standards] XEP-0283 Moved - Security and Usability
georg at op-co.de
Wed Nov 7 09:44:33 UTC 2018
I was kindly reminded to bump this thread, and to ask for actual
arguments against moving forward with making 0283 fully-automatic.
* Georg Lukas <georg at op-co.de> [2018-03-09 17:56]:
> Hi together,
> as part of Easy XMPP I wanted to have a way to completely migrate from
> one account to another, or to be able to move a subset of your contacts
> to another (local) JID. One possible side-benefit would be to get rid of
> the "jabber." substring that's so prevalent in many old server
> installations, and that's become obsolete with the invention of SRV
> XEP-0283 "Moved" provides the signaling mechanism to make this possible,
> with two "little" issues:
> 1) the Security Considerations spoil all the fun of automatic account
> | In order to prevent other users from maliciously altering contacts the
> | client SHOULD NOT automatically subscribe to a <moved/> JID when it
> | receives an unsubscribe and SHOULD NOT automatically unsubscribe to a
> | <moved/> JID when it receives a subscribe.
> I think that if our contact proves ownership of both accounts by
> publishing a <moved/> element on each, containing the respective other
> JID, there should be no security problems with automatically replacing
> the contact's JID on our roster.
> While in theory, someone with short-term access to our account will be
> able to permanently steal all our contacts, I would consider that
> account as fully compromised anyway, and the attacker can well perform
> any other kind of impersonation or social engineering attack they want.
> 2) the flow in §3.1 does an 'unsubscribe' with a payload, and most
> servers won't keep that payload after processing the unsubscribe.
> However, we could just set the <moved/> payload to a normal (directed or
> broadcasted) presence as proof of account ownership and let the
> receiving entity auto-unsubscribe once the "new" account has also
> signalled the intent to move.
> I'd like to resurrect the XEP, allow automatic approval of contacts' JID
> changes (and maybe also invent some way to also move local/MAM history
> for that contact).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Standards