Kevin Smith wrote:
On Jan 15, 2008 3:33 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:I have updated the provisional version of XEP-0115 per recent list discussion.I have only a minor word-smithing niggle: The collision and preimage section is a bit unclear - for the first halfread I though the terms were reversed (it's not vulnerable to collision, but might be to preimage sounds peculiar because collision is semi-possible, while preimage isn't), but I think I've understood now. Perhaps it could say something like 'not vulnerable to semi-possible* existing collision techniques, but could be possible to pre-image attacks if such are developed in the future." (*I forget the term). It might help thickies like me reading the spec.
I've changed the first paragraph of that section to read: ******As described in RFC 4270 [24], protocols that use the output of hash functions such as MD5 or SHA-1 can be vulnerable to collision attacks or preimage attacks or both. Because of how the hash output is used in entity capabilities, the protocol will not be subject to collision attacks even if the hash function used is found to be vulnerable to collision attacks. However, it is possible that the protocol might become subject to preimage attacks if the hash function used is found to be vulnerable to preimage attacks.
******
The 'pre-image would need' section says that it would have to remove a feature, but adding a feature could be equally DoS (say you supported xhtml-im and so the client stopped sending a <body /> as a poor example).
I've changed the relevant bullet-point to: ******The input messsage X or S' would need to make it seem as if a desirable feature (e.g., end-to-end encryption) is not supported by other entities that advertise the same hash V even though the feature is indeed supported (i.e., the attacker would need to return a set of service discovery identities and features that match X or S', and have that set be plausible for an entity that communicates via XMPP), or make it seem as if an undesirable feature is supported even though the feature is not supported.
******
I'm much happier with the text now though, thanks Peter.
I'm here for you! ;-) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
