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

Dave Cridland dave at cridland.net
Tue Sep 13 09:57:32 UTC 2011

On Mon Sep 12 22:22:01 2011, Peter Saint-Andre wrote:
> One way to solve this problem is to define a new algorithm, either  
> in a
> revision to XEP-0115 or in a new spec with a new namespace. To  
> conserve
> space in presence, we'd prefer to avoid a new namespace. So that it  
> is
> possible to continue using the vast majority of existing caps  
> hashes,
> we'd prefer to keep the algorithm the same, if that can be  
> accomplished
> in a secure way.
I sympathize. I really do. I'm also less than convinced it's an  
achievable goal.

> We thought of another approach, which has two parts...
I think both parts are massively warty.

> <feature var='!'/>

OK. The problem here is that this is not a change in XEP-0115, it's a  
change in XEP-0030, and as such has wider ramifications.

> Any software supporting this approach would need to advertise  
> support
> for the first-sorted disco feature. If an application processes a  
> caps
> input string that *not* contain the first-sorted feature, based on  
> local
> service policy it could either reject it as an attack or accept it  
> as
> using the old-style caps algorithm. (Eventually everyone would  
> regard it
> as an attack, but that might not happen for a few years.)
It's only an attack if you're doing XEP-0115 expansion, rather than  
processing XEP-0030 in isolation. But I'm concerned that it means  
that if you want to do XEP-0030 anywhere, you'll need to add in '!',  
either in order to prevent an interop failure when someone rejects  
your feature list, or to cope with future XEP-0115 cases.

> We then legislate that XEP-0128 extensions MUST use this FORM_TYPE  
> (this
> is not a major imposition since there is very little use of  
> XEP-0128 in
> the wild). Here again, if an application processes an input string  
> that
> contains a FORM_TYPE other than "urn:xmpp:clarkform", based on local
> service policy it could either reject it as an attack or accept it  
> as
> using the old-style caps algorithm.

I think this is a radical change which has a large effect on existing  

- XEP-0128 *is* used very heavily in the wild, just not (we think)  
for client capabilities. MUC rooms use this (and there are many  
consumers), to give one example.
- The FORM_TYPE is used to distinguish between sets of metadata; I  
think forcing all FORM_TYPEs used to be the same would effectively  
mean that only one XEP-0128 extension could be used, and whilst I  
cannot think of a case where this would have problems, I'm not  
convinced there isn't either.

I do want this to work; I'm not convinced it's enough, or right, and  
I do think it'll land us with a number of warts in the protocol that  
we're still in a position to avoid.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list