Hi folks. There has been quite some feedback on the entity caps problem, both on the list and off. I'm summarizing all of it, as well as my thoughts and responses.
--- The problem: The only thing the current caps XEP adds over legacy caps is obfuscation. Everything else is equivalent from a security perspective. There are four directions to consider. 1. Do nothing. I think it's safe to discard this one. 2. A new algorithm in a new XEP (with a new namespace). This is my preferred direction. There is some opposition to it, which I can understand, but do not entirely agree with. A new XEP would be 'clean', with none of the historical baggage the current XEP already has (which would only increase with the other options). And (most importantly) the transition to a new XEP would be smooth. 3. A new (not backwards compatible) algorithm in the same XEP. I'm assuming this means implementations using a different value for the 'hash' attribute than 'sha-1'. I would be against this, the reason being incompatibility. While the transition from the old to the new takes place, the amount of IQ traffic may very well exceed that of presence. This is probably the worst of all choices, with all the disadvantages of a new replacement XEP, and none of its advantages. 4. Patching the current algorithm (while keeping it backwards compatible). First, there's the argument that we already bent over backwards to keep backwards compatibility during the move to the current caps algorithm. It’s a sunk cost, and while that’s sad, it should have zero effect on the current decision. I'll discuss the solutions proposed, and problems with them. a. http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r2=3373&r1=2855 I disagree with the wording and the change. The XML parser sees '<', but anything behind the XML parser sees '<'. The wording should talk about escaping what they have. Not not escaping what they don't have (yay, triple negatives). Also, with the current wording, both &lt; and < would have the same representation (as Pedro Melo noted). Escaping using all five basic XML entities is a more proper fix. b. Forbid empty 'type' attribute on the <identity/> element. <feature var='http://jabber.org/protocol/muc'/> can still be replaced by <identity category='http:' type='/jabber.org' xml:lang='protocol' name='muc'/> Fun, eh? c. add new feature that sorts at end. Show me such a feature, and I'll show you one sorting after it. d. A special extension with FORM_TYPE value '!' There are an infinite number of strings which are allowed and sort before '!'. --- Now let’s talk about possible solutions. I should note that while I'm listing these possibilities, they all bring one word to my mind: HACK. We have three major sections (identities, features and extensions). There needs to be a separator between them. There is no possible string which would always sort last. There is a string which would always sort first, and that is the empty string "". So, with a <feature var=''/> and a form with an empty FORM_TYPE value added, we have separation between the sections. With '<' escaped, the features section is safe. With '/' not forbidden or escaped, the identity section is not safe. With some exceptions, any <identity/> element with one of the attribute values containing a '/' is open to attack. Now we are left with the service discovery extensions section. This section happens to have subsections, which are open to attack. We'll have to add a special field to every extension, so that the boundaries between extensions are preserved. Ah, of course, there also need to be boundaries between individual fields of an extension. And of course, these boundaries at three levels need to be distinguishable. Nice, no? The way I see it, there is no simple way to preserve structural information for the extensions section. It's several levels deep, which makes things _very_ complicated. I don't think this can reasonably be done while maintaining backwards compatibility. The replacement algorithm Pedro Melo suggested still has many of these issues. --- Now, moving on to incompatible changes: Many of us don't like service discovery extensions. I think this is due to the problems they are causing in the caps algorithm. While I have agreed with making them obsolete in the past, they have valid use-cases. They should be fixed (or replaced by disco#meta). --- I'm sure I had more to say, but this is all that comes to mind at the moment. I'll leave the rest for later, and wait for feedback on this message. -- Waqas Hussain
