[Standards] XEP-0283 Moved - Security and Usability
jonas at wielicki.name
Mon Mar 12 14:50:56 UTC 2018
Thanks for taking this up.
On Freitag, 9. März 2018 17:53:27 CET Georg Lukas wrote:
> 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.
This only works for mutual subscriptions. Non-mutual subscriptions can’t
easily be transferred this way I think. I also don’t think that non-mutual
subscriptions are a common case to worry about and manual intervention (as
described in §3.7.1) may be acceptable there. If we really want to make this
work automatically, additional protocol (outside of <presence/>) could be
invented for that.
> 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.
This has the downside that the receiving entity needs to support the protocol
for the unsubscribe to work automatically (while the unsubscribe would work
automatically without support on the receiving side; the subscribe would
If we assume that this feature is to be implemented server-side, I don’t see
the benefit changing this.
> 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).
Seems like a plan.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards