[Security] Trivial preimage attack against the entity capabilities protocol

Matthew Wild mwild1 at gmail.com
Wed Aug 19 14:30:05 CDT 2009


On Wed, Aug 19, 2009 at 3:47 PM, Jonathan
Dickinson<jonathan.dickinson at k2.com> wrote:
> 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).
>

If we did decide to take such drastic action for deprecating the
original spec then I vote for going the route of a new hash algorithm
to minimise disruption, confusion, and effort on the part of lazy
developers :) It also allows wise implementations to make an informed
choice about whether to trust a hash or not.

I think I'm in favour simply of using \0 as the new separator, it
being disallowed in XML in general.

And I'd like to clear up that if any existing implementations are
using "&lt;" as the separator with the current spec then they are the
exception, since an XML parser in general would always pass data
unescaped (ie. it would pass to the application "<" and not "&lt;")...
it is usually the parser's responsibility to handle XML escaping, so
for applications to use escaped strings in hash calculation would
require an extra XML-escaping step. That any mention of this step is
missing from the XEP is the root cause of the problem.

Simply using \0 protects developers from making the same mistake (and
given the opportunity someone will), whether we fix the spec or not.

Matthew


More information about the Security mailing list