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 ...
- m&m
<http://goo.gl/voEzk>
