On 8/29/11 9:18 AM, Matthew A. Miller wrote: > > On Aug 27, 2011, at 01:41, Pedro Melo wrote: > >> 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. >> > > 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.
Very much so. The point of a form is to include data, not just the mere FORM_TYPE (which would be like an XML namespace with no elements or attributes). Note that even XEP-0004 says: A data form of type "form", "submit", or "result" SHOULD contain at least one <field/> element... Is there a strong reason why that isn't MUST? Peter -- Peter Saint-Andre https://stpeter.im/
