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

Matthew A. Miller linuxwolf at outer-planes.net
Tue Sep 13 19:04:05 UTC 2011


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>

-------------- 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/20110913/439e9e4b/attachment.bin>


More information about the Standards mailing list