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

Matthew A. Miller linuxwolf at outer-planes.net
Wed Sep 14 20:37:10 UTC 2011


On Sep 14, 2011, at 13:40, Waqas Hussain wrote:

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

the caps hash would be as it is today.  So, yes, a client that doesn't understand this double-verify would still be vulnerable.

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

Being suspect means it's up to the implementation and deployment.
*  Some might accept (and cache) them but with a log message somewhere.
*  Some might reject (and not cache) them unconditionally.
*  Some might put in a timebomb into their implementations that will switch from "accepted" to "rejected".

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

The point of trying to keep the old XEP is not to eliminate a transition, but to make it less painful.  I do think having a complete replacement to caps is more painful than applying an addendum or two.  As Dave said, the building is not burning (yet).


- m&m
<http://goo.gl/voEzk>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2238 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110914/7a69e70a/attachment.bin>


More information about the Standards mailing list