[Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities

Waqas Hussain waqas20 at gmail.com
Wed Sep 14 22:31:53 UTC 2011


On Thu, Sep 15, 2011 at 1:37 AM, Matthew A. Miller
<linuxwolf at outer-planes.net> wrote:
>
> On Sep 14, 2011, at 13:40, Waqas Hussain wrote:
>
>>
>> So.. which caps is included in presence? The current exploitable one?
>> Then this doesn't help with preventing poisoning, does it?
>>
>
> the caps hash would be as it is today.  So, yes, a client that doesn't understand this double-verify would still be vulnerable.
>

An entity which understood double verify would have the option to
either be vulnerable to poisoning, or participate in IQ floods. It's
this that I'm against.

>> What does considering the result suspect mean? I'm hoping you don't
>> mean it isn't cached. Because that would be much worse than just using
>> a new XEP, which would be a perfectly smooth transition.
>>
>
> Being suspect means it's up to the implementation and deployment.
> *  Some might accept (and cache) them but with a log message somewhere.

Err....

So poisoning succeeds. And what happens with these logs? How do you
find the poison needle in the haystack of legitimate messages? I hope
you don't want admins to do this...

> *  Some might reject (and not cache) them unconditionally.

And therefore early adopters are punished with IQ floods...

> *  Some might put in a timebomb into their implementations that will switch from "accepted" to "rejected".

I just don't like this particular idea...

>
>> I have assumed the whole point of all this effort to keep the old XEP
>> is to get rid of the transition period, so if you are not going to
>> cache exploitable caps at all, might as well define a clean new XEP.
>
> The point of trying to keep the old XEP is not to eliminate a transition, but to make it less painful.  I do think having a complete replacement to caps is more painful than applying an addendum or two.  As Dave said, the building is not burning (yet).
>

I see. Frankly I was (and still am) confused at what the point was.

Make it less painful? For whom?

Less painful for developers? I disagree that adding tons of extra
checks and magic disco features and forms is going to make developers
happy. A nice clean separate algorithm is much more likely to do that.

Less painful for users/server-admins? Your particular proposal gives
them IQ floods (most of the proposals from stpeter do not have this
issue).

Less painful for spec writers? I don't think so.

This is how I see it:
stpeter's proposals: 1. dont succeed in fixing the issue, 2. don't
have the flood issue, 3. don't add anything to presence, 4. complicate
the spec.
your proposal: 1. either doesn't fix the issue, 2. or causes floods,
3. doesn't add anything to presence, 4. complicates the spec, as both
the current and new algorithms are now part of it.
new XEP: 1. fixes the issue, 2. doesn't cause floods, 3. does add
something to presence during the transition, 4. simplifies the spec.

Oh, and I agree there is no burning building. I don't think anyone
thinks there is at the moment.

>
> - m&m
> <http://goo.gl/voEzk>
>
>

--
Waqas Hussain



More information about the Standards mailing list