On Wed, Sep 14, 2011 at 12:04 AM, Matthew A. Miller <[email protected]> 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
