security text tweaks

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1581 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0115.xml

@@ -446,7 +446,7 @@
       <p>In the future, the &COUNCIL; may, at its discretion, modify the mandatory-to-implement hashing algorithm if it determines that SHA-1 has become practically vulnerable to <link url='#security-preimage'>Preimage Attacks</link>.</p>
     </section2>
     <section2 topic='Preimage Attacks' anchor='security-preimage'>
-      <p>Although the entity capabilities protocol is not vulnerable to collision attacks, it may become possible to launch a preimage attack against the hashes used as the values of the 'ver' attribute in the entity capabilities protocol (on the difference between collision attacks and preimage attacks, see &rfc4270;).</p>
+      <p>As described in &rfc4270;, 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 <em>possible</em> that the protocol might become subject to preimage attacks if the hash function used is found to be vulnerable to preimage attacks.</p>
       <p>In theory, such a preimage attack would take one of the following forms:</p>
       <ul>
         <li>Given knowledge of a particular value V of the 'ver' attribute, an attacker can find an input message X such that hash(X) yields V (this is known as a "first preimage attack").</li>
@@ -457,7 +457,7 @@
         <li>The hashing algorithm used would need to be found not only theoretically but practically vulnerable to first or second preimage attacks (e.g., this is not yet true of the MD5 or SHA-1 algorithms, but may become true in the future).</li>
         <li>An attacker would need to find an input message X or S' that matches the hash V for a particular value of V or S, which may not be practical given that (a) the values of S used as input to the hash function in entity capabilities are relatively short and (b) cryptanalysis to date indicates that existing hash functions may not be vulnerable to preimage attacks except in the case of relatively long input messages (on the order of 2<span class='super'>55</span> blocks).</li>
         <li>The input message X or S' would need to conform to the structure of S as specified under <link url='#ver'>Generation of the ver Attribute</link>, including the order of service discovery identity or identities followed by service discovery features, delimited by the '&lt;' character and sorted using "i;octet" collation.</li>
-        <li>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).</li>
+        <li>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.</li>
         <li>The attacker would need to propagate the hash V before some other entity with the true input message S could broadcast presence with the relevant entity capabilities data and provide the true service discovery response (thus the attacker might need to subvert the development process of a particular software project or subvert the namespace issuance process of the &REGISTRAR;, or both).</li>
       </ol>
       <p>It currently seems extremely unlikely that an attacker could meet all of the foregoing conditions in the foreseeable future. However, the XMPP Council shall continue to monitor the state of cryptanalysis regarding the mandatory-to-implement hash function as well as the possibility that any vulnerabilities in that function might lead to practical threats against the entity capabilities protocol. If and when it becomes practical (or even possible) to launch effective preimage attacks against the entity capabilities protocol, the XMPP Council shall consider updating this specification to change the mandatory-to-implement hashing algorithm to a safer technology.</p>