On Aug 27, 2011, at 01:41, Pedro Melo wrote: > Hi, > > On Sat, Aug 27, 2011 at 12:52 AM, Matthew A. Miller > <linuxw...@outer-planes.net> wrote: >> On Aug 26, 2011, at 16:32, Waqas Hussain wrote: >>> On Sat, Aug 27, 2011 at 1:53 AM, Samantha Mizzi <sami...@cisco.com> wrote: >>> The proposed changes don't solve the problem. See what I wrote in the >>> "Attempting to fix the algorithm" section of the email you linked. >>> Particularly "As far as I can see, there is no way of fixing attacks 2 >>> and 3 other than fundamentally changing the algorithm." >> >> Attacks #3 and #4 should not be successful, because they violate the schema >> for disco#info; the category and type attribute values MUST be present, and >> MUST be non-empty strings. >> >> As for attack #2, I wonder how worthwhile it is to send a disco extension >> that only contains a FORM_TYPE. Verifying that each form has at least one >> non-FORM_TYPE var-ed field might be enough to prevent this attack. > > You are right, but if possible it would be better to have an algorithm > whose security is not based on restrictions that for some reason we > might want to lift later. >
I do appreciate this position in general, but let's look at this particular case. Disco extensions are additional information about an entity that doesn't fit in <identity/> or <feature/>. We've already set the precedence with MUC and PubSub to use features as flags, so using this in the same manner seems a little phishy to begin with. This kind of restriction (or security consideration?) is starting to look like something we ought to have put on XEP-0128 in the first place. > >> The suggestion was to encode '<' not forbid it, as the authors originally >> intended but neglected to codify. >> >> As for forbidding '/' within category, type, and xml:lang values, I >> personally don't see a problem with this. None of the currently registered >> categories and types contain '/', and I'm aware of a number of >> implementations that will break if category or type contain '/'. The >> structure of the xml:lang attribute already forbids any character that's not >> a letter, digit, or hyphen. > > I would rather not have to worry about looking into the data of these > attributed, given that we want implementors/developers to look at > them as opaque most of the time. > The category, type, and xml:lang values are not really opaque values except for caps. Implementations are supposed to take semantic meaning from them in general, that's the whole point for their existence (-: Maybe this is why I don't have a problem with a couple extra restrictions. > True, encoding doesn't break opacity, but still, if we can avoid it... > > >>> I'm still in favor of a clean new algorithm and XEP, which can also fix >>> many of the non-algorithmic issues with the XEP. >> >> I personally would like to explore the possibilities we might have to fix >> things with as small an impact as possible. > > Whatever change is proposed and finally adopted will trigger a new NS, > hopefully switching to the new URN-style. > I'm not yet fully convinced *any* change will automatically trigger a new namespace. Particularly if what we're doing is tightening up considerations. > At the time, the best suggestion I saw with minimal changes was to > separate the items with a invalid (in XML terms) octet, and double the > octet for each section. Don't remember if it was checked to see if > indeed solved it. > It doesn't appear that actually went anywhere, either. And I'm not yet fully convinced that is the most minimal change we can make. And, yes, I have been accused of flogging dead horses on occasion (-: > Today, I would look at the the XML canonical forms floating around to > see if any of them is simple enough or widely deployed to be used as > the encoding for the input to the hash function. > As far as I know, <http://www.w3.org/TR/xml-c14n> is the most widely deployed, but it's definitely not in most places, let alone everywhere. It's practically impossible unless you keep the original structure of the XML around to perform the canonicalization from, such as original namespace prefixes. > If that turns out to be too complex, I can revive an old algorithm I > had laying around at the time that (as far as I remember) would solve > the pre-image attacks, keep the opaque stuff untouched and provide > extensibility hooks to extend the information announced in the future. > Please share (-: - m&m <http://goo.gl/voEzk>
