On 8/29/11 7:30 PM, Matthew A. Miller wrote: > > On Aug 29, 2011, at 18:40, Peter Saint-Andre wrote: > >> 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? >> > > That sounds reasonable to me. I would go further, and update either > XEP-0068 or XEP-0128 to somewhere have: > > MUST have at least one other <field/> element ...
Yes, I think that belongs in XEP-0068 because it applies to all forms scoped via the FORM_TYPE mechanism. Peter -- Peter Saint-Andre https://stpeter.im/
