Hi Georg, 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 > > transfers: > | 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 obviously not). 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. kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
