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

Dave Cridland dave at cridland.net
Fri Sep 16 21:26:34 UTC 2011


On Fri Sep 16 21:15:43 2011, Florian Zeitz wrote:
> Hence a new protocol dropping the old one at the same will:
> a) Make old implementations send IQ queries to the new  
> implementations.
> Number of IQs increases with the number of implementers of the new
> protocol for some time, but at a certain point that turns and the  
> more
> people implement the new protocol the fewer IQs we get.

Of course this can be avoided by maintaining the existing caps  
protocol...


> b) Gives us a clean cut without ugly hacks (which may or may not  
> even work)
> c) Keeps presence about the same size

... which does increase the size of stanzas, but I don't think  
that'll be a concern.


> d) Breaks e.g. PEP on servers, however I'm under the impression that
> servers are easiest to get updated since there is some competition  
> there
> (cf. SCRAM).

The problem isn't the individual implementations; it's the deployed  
state.

We know that at least some XEP-0115 consumers don't bother examining  
them if there isn't a hash-based XEP-0115 caps.

I think it's worth stepping back and re-examining what we need from  
caps, and what we could get, as a first step.

To give an example, we could have receivers of unknown caps ask their  
localserver to expand them - this would radically reduce traffic on  
the network as a whole, and their local server will probably need to  
know the features anyway for PEP, etc.

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