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:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
