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

Waqas Hussain waqas20 at gmail.com
Mon Sep 5 17:51:16 UTC 2011

On Mon, Sep 5, 2011 at 5:39 PM, Dave Cridland <dave at cridland.net> wrote:
> On Wed Aug 31 06:48:26 2011, Waqas Hussain wrote:
>> Most protocol attacks are based on unexpected input. Attackers
>> wouldn't really care whether the values they send are registered or
>> usable in any way, as long as the attack succeeds. I don't think you
>> are proposing all caps handling entities ship with a copy of the
>> registry and fail on anything not included.
> No, but we could potentially restrict input quite heavily.

Disco extensions remain a sticky point, and I dislike forbidding '/'
in identity.name.

> Let's say that we add (yet) another attribute to the caps element,
> indicating that the "new" restrictions are in place. (These might include
> the various restrictions mentioned in this thread).
> Now, when a client sees a caps marked as restricted, it can validate the
> disco#info it gets.
> If a client sees two caps strings, one marked as restricted and one not, it
> should assume that the caps string is intended to be restricted as proceed
> accordingly.

That's a fairly interesting idea. More thinking required.

> I'm also wondering if it's worth considering optional (and marked) removal
> of XEP-0128 in cases where it's not used.
> Of course, it may be simplest just to bite the bullet and switch hash
> algorithm - or even change the 'hash' attribute name - because then it'll
> get treated as a pre-1.4 caps by the vast majority of entities and
> everything will happen right (or at least, no worse than it often does today
> anyway).
> I'm gradually leaning toward this, because although it's *quite* violent,
> the downside is not impossible.

The transition should be smooth. I was initially for fixing the
current protocol, and would be for it if we found a good way to do so.

> BTW, anyone any idea what happens if you include more than one <c/> in a
> presence, in practical terms?

I suspect some would pick the first and some the last. That's the two
kinds of child-element-scanning logic I've seen in clients. I don't
think we can depend on any behavior here.

Also, see last discussion about getting rid of order attribute in
privacy lists :)

>> I know Miranda and Tkabber send software version. Probably many
>> others. Can we gather stats on jabber.org for this?
> M-Link cannot capture that data, except by capturing all traffic (which is
> inadvisable).

Sad. I'd hoped there would be a way to dump the PEP caps table.

> I would re-iterate that we still have no burning building. We're getting
> closer, though.

I don't disagree. That's why I never really pushed for getting this
resolved instantly. It's an annoyance, but not a burning building at
the moment.

> Dave.

Waqas Hussain

More information about the Standards mailing list