[Standards] OBSOLETED: XEP-0071 (XHTML-IM)
jonas at wielicki.name
Thu Mar 8 07:51:26 UTC 2018
On Donnerstag, 8. März 2018 07:54:04 CET Evgeny Khramtsov wrote:
> Wed, 07 Mar 2018 21:33:13 +0300
> Kozlov Konstantin <yagiza at yandex.ru> wrote:
> > So, the only reason to obsolete the XEP is not the XEP itself, but
> > bad implementations?
> Yes. This is kinda religion among some Council members that if a
> technology can be misused then it should be deprecated. Their religion
> is, however, quite picky: there is a well-known list of security
> problems in XML (including the famous billion laughs attack), but they
> don't consider to get rid of XML.
How many XMPP clients have you seen which were owned by Billion Laughs (which
uses entities which are explicitly forbidden in RFC6120 and trivial to turn
off in all XML parsers I’ve seen so far) compared to the amount of XMPP
clients Sam has found which were vulnerable to XHTML-IM XSS attacks? I think
the comparison might not hold up, but I’m open for data. (Likewise for any
other XML vulnerability.)
Maybe you could make a server module which stress-tests clients against that
type of input. I’d be interested, but that’s off-topic to the XHTML-IM
Also, XML vulnerabilities are both well-known and easy to test against (in the
sense: it is easy to write an automated test which ensures that code is not
vulnerable). I don’t think that’s so trivial with XSS attacks. During the
XHTML-IM debate I learnt that even CSS can be an XSS vector (in some really
broken implementations; not to mention possible privacy implications by using
background: url(…) etc.), at which point I concluded for myself that XHTML-IM
as it is is irresponsible because sanitization is so complex that nobody is
going to do it completely, and those who are will most likely get it wrong.
(My proposal to have someone create a reference implementation of a sanitizer
in a language which would be most-reusable in this domain (probably JS) and
have it professionally reviewed unfortunately didn’t gain traction.)
In contrast to XML, XHTML-IM is a custom thing which needs to be re-
implemented in ~every client. Well-known XML libraries exist for most
languages (even if they only FFI to libxml2 or libexpat).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards