<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<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 ("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."); 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.
From: Joe Hildebrand <firstname.lastname@example.org>
Sent: Tuesday, August 18, 2009 2:18 PM
To: XMPP Security <email@example.com>
Subject: Re: [Security] Trivial preimage attack against the entity        capabilities protocol
<div>On Jul 31, 2009, at 8:59 PM, Peter Saint-Andre wrote:</div>
<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>
<div>Backward-compatibility is very important to me. There is a LOT of XEP-115 deployed out there. My preferences are:</div>
<div>1) characterize exactly the sorts of strings that lead to attack. Put wording in the XEP that allows detecting those attacks by disallowing certain combinations. 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>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>3) move extensions to deprecated, and have everyone who sends extensions be viewed with suspicion. 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>