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

Matthew A. Miller linuxwolf at outer-planes.net
Tue Sep 13 18:18:57 UTC 2011


On Sep 13, 2011, at 03:57, Dave Cridland wrote:

> 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.
> 

Can you expand on this?  I must be missing something, but I don't see how the lack of a '!' feature in, say, a MUC service's disco#info result means it's rejected.

Also, what does 'rejected' mean in terms of XEP-0030 but *not* in terms of XEP-0115?

>> 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 uses.
> 
> - 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.
> 

The intent was not every place XEP-0128 is used, but where XEP-0128 is used in conjunction with XEP-0115.  I will admit that this change is the most bothersome to me, too.

> 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.
> 

I've been thinking of something that might be a less-awful compromise.  I'll post to this list about it soon for us all to mock and ridicule (-:


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2238 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110913/629a433c/attachment.bin>


More information about the Standards mailing list