[Standards] Re: [jdev] XEP-0115: Entity Capabilities

[Dave Cridland]

On Wed Jul  4 11:35:54 2007, Ian Paterson wrote:
> Dave Cridland wrote:
>> The hard part remains the timing issue - in order to have any 
>> value, you'd need to pollute the target clients capability cache 
>> prior to it discovering the real capabilities, and that's an 
>> extraordinarily short time window.
> 
> It's not short if the attacker discovers the hash value of early 
> "betas" of a new version of a popular client. This approach 
> typically would allow a few months to find an appropriate collision 
> (using a bot net?). Once found, the attacker would polute users' 
> caches and then wait for the users to upgrade to the final released 
> version of the client.
> 
> 
Indeed, although it still requires a second preimage attack, and I'm 
not aware of any against MD5. See below for a strategy to reduce this.


>> FWIW, I lean heavily toward pre-defined sets, as I think that 
>> "good clients" gain in both security and efficiency, whereas "old 
>> clients" are unaffected.
> 
> Yes, the XEP could mention the possibility of "pre-defined sets" in 
> the implementation issues section.
> 
> Of course clients can ship with pre-defined sets even if we 
> depricate 'ext'. IMHO, 'ext' offers only marginal improvements to 
> pre-defined security, network traffic and cache storage space. 
> Eliminating 'ext' allows us to significantly simplify client logic.

The scenario you mentioned above becomes significantly more difficult 
with ext in play, especially if predefined sets are the norm.

The "new beta" would still have a known ver hash (from XEP-0211, or 
perhaps XEP-213), and probably the same ext hashes as previous 
version (many of which might also be known a priori). Only the "new" 
features special to the new beta would be in a previously unknown 
hash, and therefore vulnerable to a caps-pollution attack. And these 
would only be vulnerable if these "new" features didn't form, or 
complete, a predefined set the client already knew about (whether by 
hardcoding, or because there were already deployed clients with this 
set advertised that it had previously probed).

I agree that this is additional cost in terms of complexity, and I'd 
probably argue against it if it weren't mostly in place already.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade