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

Dave Cridland dave at cridland.net
Mon Sep 5 19:54:58 UTC 2011


On Mon Sep  5 18:51:16 2011, Waqas Hussain wrote:
> 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.
> 
> 
I think we could cope.


> > 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.
> 
> 
Right, it's not a fully fleshed-out solution, for sure.


> > 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.
> 
> 
We have sufficient pre-1.4 support out there to cope this way,  
basically. I think any entity seeing pre-1.4 caps just doesn't verify  
them at all, in practise.


> > 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 :)
> 
> 
Yup, I thought that might be the case.


> >> 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.
> 
> 
There possibly is, I think, but M-Link R14.6 ignores all non-+notify  
features, and M-Link R15.0 ignores XEP-0128 (at least, without  
disco-caching on).

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