<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<pre style="word-wrap:break-word; font-size:10.0pt; font-family:Tahoma; color:black">This may be a bit extreme but how about a V2 115? This would come up as a feature with a new namespace (alongside the old one). If the old one would be selected the server would transparently intercept it and send the originating user a warning (&quot;Your Jabber client is using old and flawed technology which could present a security risk. Please update it or contact the developers about XEP-115.&quot;); at such a point we could kill the standard (not just deprecate it) the server could ignore the stanza (and never route it).

This kind of functionality would be great for deprecating standards - not 115 alone; but any bloopers we could make in the future.

Sent from my Windows® phone.

-----Original Message-----
From: Joe Hildebrand &lt;hildjj@gmail.com&gt;
Sent: Tuesday, August 18, 2009 2:18 PM
To: XMPP Security &lt;security@xmpp.org&gt;
Subject: Re: [Security] Trivial preimage attack against the entity        capabilities protocol

</pre>
<div><br>
<div>
<div>On Jul 31, 2009, at 8:59 PM, Peter Saint-Andre wrote:</div>
<blockquote type="cite">
<div><font class="Apple-style-span" color="#000000"><br>
</font>I haven't yet had time (at least since the XMPP Summit last week) to<br>
think more about this problem. We did a lot of work in the more recent<br>
versions of XEP-0115 to maintain backward compatibility, and it would be<br>
a shame to lose all that work now. But sometimes sunk costs are a fact<br>
of life...<br>
</div>
</blockquote>
</div>
<br>
<div>Backward-compatibility is very important to me. &nbsp;There is a LOT of XEP-115 deployed out there. &nbsp;My preferences are:</div>
<div><br>
</div>
<div>1) characterize exactly the sorts of strings that lead to attack. &nbsp;Put wording in the XEP that allows detecting those attacks by disallowing certain combinations. &nbsp;I'm not sure if that's possible, but, for example, forbidding empty type attributes in identities
 might mitigate attacks 2 and 3.</div>
<div><br>
</div>
<div>2) add a new feature that sorts at the end, or a new extension that sorts at the front to signal the shift between features and extensions</div>
<div><br>
</div>
<div>3) move extensions to deprecated, and have everyone who sends extensions be viewed with suspicion. &nbsp;This is a distant last for me, since there were valid compromises that went into the inclusion of extensions in the first place. The last thing I want is
 for clients to go back to sending iq:version to everyone on the roster every time they receive presence.</div>
</div>
</body>
</html>