[Standards] [Fwd: Re: Namespace well-formedness and RFC3920bis backwards compatibility]
stephan at spaceboyz.net
Fri Sep 19 19:00:52 UTC 2008
Dave Cridland <dave at cridland.net> wrote:
> Given that ejabberd apparently cannot do this easily, [...]
> In our case, I'm pretty sure that if we receive XML which is not
> namespace-well-formed, we'll pass it through in some, and possibly most
> circumstances. In some circumstances, we'll be forced into parsing the
> stanza contents, in which case we'll at least see the problematic prefix,
> but these are highly limited circumstances in the traditional forward case -
> the majority of the time we don't parse the inner XML of stanzas, and doing
> so would be a significant performance hit to us.
Under which circumstances are inner elements not parsed?
> The fact is there's no good reason clients should be generating bad XML, and
> while there's obviously a benefit to servers rejecting it if possible, it's
> a reasonably well-known denial of service attack and the existing deployment
> doesn't always strip out bad prefixes etc in all cases. Therefore I think
> clients need to be made resilient to these attacks whatever the next RFC
> revision says, and in particular, we should be moving to a situation whereby
> clients don't choke and drop the connection when they get bad XMLNS like
It is a big problem that a lot of clients base on standard XML libraries
which in the case of an unbound namespace prefix choke, report an error
and entirely refuse to continue parsing.
> And given that circumstance, it seems to me that requiring servers to always
> detect and reject bad prefixes is distinctly onerous.
Which is bit orthognal to XMPP's philosophy of complexity on the
server-side and valid XML everywhere.
> Instead, stanzas which are not namespace well formed SHOULD be rejected by
> the recipient [with a stanza error], and SHOULD NOT cause a disconnect in
> clients [ie, don't let this be a DOS]. Clients MUST NOT generate XML which
> is not namespace well formed [clients have no excuse for this behaviour],
> servers SHOULD NOT forward such XML and MUST NOT generate it [newly minted
> XML won't have this problem]. Servers MAY disconnect clients which generate
> bad XMLNS [potential DOS], however this does not apply to peer servers.
I agree. Unless all XMPP servers block invalid stanzas from clients it
is bad that s2s links will be shut down upon encountering an unbound
namespace prefix. Having one bad client will affect other users on the
> I think if we require unconditional stringency in servers, that'll either be
> ignored as impractical, or result in XMPP being slower than it really needs
> to be, or - most likely - both. If client authors rely on it, then there's
> sufficient deployed mass out there that it's likely to be used for DOS
> purposes for years.
I am interested in a real-work benchmark/profiling of my patch.
More information about the Standards