On Sep 14, 2011, at 13:40, Waqas Hussain wrote: > 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? >
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>
smime.p7s
Description: S/MIME cryptographic signature
