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

[Dave Cridland]

On Tue Jul  3 23:45:53 2007, Justin Karneges wrote:
> Apologies for not understanding this thread at all and just 
> commenting out of nowhere, but what security is gained by using a 
> hash in the caps protocol?  

It's an attempt at preventing a theoretical attack, as I understand 
things. The only instance of caps "pollution" being an issue appears 
- from my reading of this thread - to be an inadvertant error, not a 
deliberate attack.


> If there is no security gained by using a hash (e.g. everyone has 
> access to the raw data such that they can all calculate the same 
> hash) then what difference does it make which algorithm is used?
> 
> 
I know Ian and Joe have answered this, I'm hoping I might add a 
different perspective on this, plus there's actually a new point at 
the bottom. :-)

In principle, an attacker capable of mounting a selected preimage 
attack (specifically, one that involves being able to create a caps 
list such that it produces a hash identical to that provided by 
legitimate clients *and* it gains some benefit to the attacker, in a 
reasonable timeframe) might be able to subvert communications.

An example of this might be convincing a client that one or more 
users on the roster are, contrary to reality, unable to handle 
esessions, or some new encrypted Jingle, enabling the attacker to 
eavesdrop communications. To do this, the attacker has to detirmine 
the "real" hash, use the preimage attack to find a caps list to 
supply by disco which is both syntactically correct and excludes the 
extensions that the attacker wishes to remove, do so before the 
target client can query any "real" clients, and finally place 
themselves in a position such that they answer such queries.

The latter can be achieved either by sending a directed presence or 
by subverting the server entirely - we can treat this as the easy bit.

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.

A simple MD5 hash will adequately prevent any chance of inadvertant 
cache pollution, which leaves the selection of any hash algorithm 
purely down to the time it'd take to mount a preimage attack.

I've reviewed the various papers on MD5 as best I can, and I don't 
think its known weaknesses are such that a preimage attack can be 
mounted within a useful timeframe, hence I'm not too fussed, but I'd 
be happy to see SHA-1 used if people are genuinely concerned. 
Whatever we choose, hash functions are continually eroded, and what's 
reasonable now will not be in the future.

(FWIW, Ian's mention of a "one hour attack" is a collision attack, 
not a preimage attack, and finds a pair of two-block messages which 
collide, both of which have specific properties, and the time figures 
are quoted for an IBM P690, which is somewhat bigger iron than I have 
about, anyway. Our attacker needs a selected preimage attack, and 
will almost certainly need one where the legitimate message is 
several blocks long for MD5, and their primary source of computing 
power is likely to be a distributed botnet at best - I'm not clear if 
this attack is distributable or not, but I'm not concerned by it).

I mentioned earlier that we could gain a benefit from ver/ext by 
using "prepackaged" sets of capabilities, in order that there was 
more likelyhood of a cache-hit, and moreover, allows clients to ship 
with a hardcoded cache containing these prepackaged sets already, 
avoiding the need to probe at all.

I think it might be worth noting that the more commonality we have 
between clients in this respect, the harder it is to mount such an 
attack, although correspondingly higher gains can be made. If clients 
are able to ship with a pre-polulated cache, then the window of 
opportunity for an attacker vanishes entirely for those clients, 
however, allowing those clients to effectively claim immunity from 
such attacks. Sorry, it's another trade-off.

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.

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