[Standards] [Fwd: Re: Namespace well-formedness and RFC3920bis backwards compatibility]

Dave Cridland dave at cridland.net
Fri Sep 19 10:10:37 UTC 2008

On Fri Sep 19 08:51:14 2008, Sergei Golovan wrote:
> Does this 'MUST NOT accept' mean that it must not also forward it  
> to other
> entities?
Yes, that would be accepting it.

> >
> >> Ejabberd happily accepts namespace-ill-formed stanzas, I don't  
> know
> >> about other servers.
> >
> > That's a bug and I thought it was corrected in version 2.x.
> When I talked to ejabberd author he said that this bug will never  
> be fixed until
> it will be absolutely clear from reading RFC that it's a bug.

Given that ejabberd apparently cannot do this easily, and I spent  
well in excess of a week handling some fairly annoying cases of  
namespaces in M-Link, I suggest that we work to address this with  
rather more pragmatism that simply requiring perfection. Perfect is  
the enemy of good, and in this case, it's the enemy of fast, too.

I think we're safe in saying that MUST NOT accept or generate XML  
which is not well-formed, and I'll assume this is beyond argument.  
(Otherwise you can't tell where the stanza ends, which further  
implies that non-well-formed XML gets you a disconnect).

If we want to have "MUST NOT accept non-namespace-well-formed",  
though, we'll have to accept that in many implementations, this is  
not terribly easy to achieve without taking a sizeable performance  
hit, or a vast amount of recoding, or quite possibly both.

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.

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 this.

And given that circumstance, it seems to me that requiring servers to  
always detect and reject bad prefixes is distinctly onerous.

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 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.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list