On Samstag, 26. Juni 2021 14:31:02 CEST Sam Whited wrote: > Another thought: > > Any spec that triggers traffic to a third party JID based on other > incoming traffic can be used for DOS amplification attacks. This one > seems only somewhat vulnerable (max payload size of the pubsub element + > max JID size bytes) but any of them can also become worse if > implementations have flaws (such as naively copying the payload which > could also result in any unknown garbage elements on the end being > copied, making the attack much worse if vulnerable clients existed).
Yikes. The concerns are valid, but as you say, in this case it is probably OK. Adding the "do not copy random payloads over" to the Security Considerations is probably sane, though the <presence/> <-> <iq/> protocol break probably takes care of that anyway. (Or am I looking at the wrong place?) > It may be worth mentioning this in the security considerations section, > or providing a way to verify by a push from the old account instead of > querying it. I think this has more issues. Off the top of my head: - PEP notifications are only delivered to online resources (via '115 caps "subscription") -- if no resources are online, the contact’s server will not hear about it - Explicit subscription to the moved PEP node on presence subscription would be possible, but requires even more server support - Delivery of <message/>s is unreliable -- if the s2s link breaks at the wrong time, verification would fail - Servers would have to cache verification information (either the pending verification from an inbound <presence type="subscribe"/> until the PEP push arrives or the verification information which was pushed via PEP until the presence arrives); this requires persistent storage, which may be more expensive (especially at scale) than the CPU/Bandwidth cost of the above DoS vector, especially if rate limiting is applied. 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 _______________________________________________
