[Security] Trivial preimage attack against the entity capabilities protocol

Jonathan Dickinson jonathan.dickinson at k2.com
Wed Aug 19 09:47:26 CDT 2009

This may be a bit extreme but how about a V2 115? This would come up as a feature with a new namespace (alongside the old one). If the old one would be selected the server would transparently intercept it and send the originating user a warning ("Your Jabber client is using old and flawed technology which could present a security risk. Please update it or contact the developers about XEP-115."); at such a point we could kill the standard (not just deprecate it) the server could ignore the stanza (and never route it).

This kind of functionality would be great for deprecating standards - not 115 alone; but any bloopers we could make in the future.

Sent from my Windows® phone.

-----Original Message-----
From: Joe Hildebrand <hildjj at gmail.com>
Sent: Tuesday, August 18, 2009 2:18 PM
To: XMPP Security <security at xmpp.org>
Subject: Re: [Security] Trivial preimage attack against the entity      capabilities protocol

On Jul 31, 2009, at 8:59 PM, Peter Saint-Andre wrote:

I haven't yet had time (at least since the XMPP Summit last week) to
think more about this problem. We did a lot of work in the more recent
versions of XEP-0115 to maintain backward compatibility, and it would be
a shame to lose all that work now. But sometimes sunk costs are a fact
of life...

Backward-compatibility is very important to me.  There is a LOT of XEP-115 deployed out there.  My preferences are:

1) characterize exactly the sorts of strings that lead to attack.  Put wording in the XEP that allows detecting those attacks by disallowing certain combinations.  I'm not sure if that's possible, but, for example, forbidding empty type attributes in identities might mitigate attacks 2 and 3.

2) add a new feature that sorts at the end, or a new extension that sorts at the front to signal the shift between features and extensions

3) move extensions to deprecated, and have everyone who sends extensions be viewed with suspicion.  This is a distant last for me, since there were valid compromises that went into the inclusion of extensions in the first place. The last thing I want is for clients to go back to sending iq:version to everyone on the roster every time they receive presence.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/security/attachments/20090819/3d370c8a/attachment.htm>

More information about the Security mailing list