Hi, On Sat, Aug 27, 2011 at 12:52 AM, Matthew A. Miller <[email protected]> wrote: > On Aug 26, 2011, at 16:32, Waqas Hussain wrote: >> On Sat, Aug 27, 2011 at 1:53 AM, Samantha Mizzi <[email protected]> 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. > 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. 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. 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. 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. 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. Bye, -- Pedro Melo @pedromelo http://www.simplicidade.org/ http://about.me/melo xmpp:[email protected] mailto:[email protected]
