[Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities

Waqas Hussain waqas20 at gmail.com
Wed Sep 14 19:40:12 UTC 2011


On Wed, Sep 14, 2011 at 12:04 AM, Matthew A. Miller
<linuxwolf at outer-planes.net> wrote:
>
> On Sep 13, 2011, at 12:18, Matthew A. Miller wrote:
>
>
>> I've been thinking of something that might be a less-awful compromise.  I'll post to this list about it soon for us all to mock and ridicule (-:
>>
>
> So, the less-awful compromise I was talking about is this:
>
> We develop a XEP-0128 extension that defines how to canonicalize and hash disco#info results, which fixes all of the known issues with caps' current canonicalization and can be applied to any disco#info result. e.g.:
>
> <query xmlns='http://jabber.org/protocol/disco#info'>
>  <identity category='service' type='im' xml:lang='en' name='XMPP server'/>
>  ...
>  <feature var='http://jabber.org/protocol/disco#info'/>
>  <feature var='http://jabber.org/protocol/disco#items'/>
>  ...
>  <x xmlns='jabber:x:data' type='submit'>
>    <field var='FORM_TYPE'>
>      <value>urn:xmpp:discohash:0</value>
>    </field>
>    <field var='algo'>
>      <value>SHA-1</value>
>    </field>
>    <field var='hash'>
>      <value>EHdJI0CahGt8XjSWUz59ODb4OrY=</value>
>    </field>
>  </x>
> </query>
>
> In terms of XEP-0115, a "concerned" implementation would first look and validate this hash (according to the new TBD spec).  If this extension is missing it might consider the disco results suspect (and still validate the XEP-0115 hash) or outright invalid (maybe sometime in the distant future).  If present and valid, it could either A) assume the caps hash is valid (if just mildly concerned), or B) validate the caps hash but confident it will not find any of the known attacks to XEP-0115 (if correctly paranoid).
>
> It does mean a fully-conforming implementation is canonicalizing and hashing twice (once for the TBD spec, once for XEP-0115), but it does mean existing implementations would still work in both directions. Plus, we could then use this for any disco#info result, potentially applying a cryptographic signature.
>
>
> Thoughts?
>
> - m&m
> <http://goo.gl/voEzk>

So.. which caps is included in presence? The current exploitable one?
Then this doesn't help with preventing poisoning, does it?

What does considering the result suspect mean? I'm hoping you don't
mean it isn't cached. Because that would be much worse than just using
a new XEP, which would be a perfectly smooth transition.

I have assumed the whole point of all this effort to keep the old XEP
is to get rid of the transition period, so if you are not going to
cache exploitable caps at all, might as well define a clean new XEP.

--
Waqas Hussain



More information about the Standards mailing list