[standards-jig] Security problems with JEP-115

Jacek Konieczny jajcus at bnet.pl
Mon Sep 22 06:55:46 UTC 2003

On Sun, Sep 21, 2003 at 03:22:04PM -0600, Peter G. Millard wrote:
> Justin Karneges wrote:
> >
> > This would mean that we'd lose out on the optimization of minimizing
> > requests to the same client software, but I don't think this a huge
> > loss, as it is probably less than 1% of the bandwidth saved out of
> > the total that JEP-115 provides.
> Um, this is kind of the whole point to JEP-115. To eliminate the
> mass-duplication when I have 20 Psi users on my roster and I have disco all
> of them. If we eliminate the optimizations, then we're basically back to
> sending everyone in my roster a disco request, which is precisely what we're
> trying to eliminate.

So maybe just remove bundle names. Asking for each bundle gives quite
a lot of additional trafic and probably clients would often support the
same bundles.

My proposition is following:

client would concatenate category/type information and all supported
namespaces (both sorted alphabetically first) and compute MD5 hash of
resulting string. 

The MD5 hash would be announced in <presence/> stanzas as "feature tag".

This way all clients (not matter what software) which implement the same
namespaces would send the same "feature tag", and the "feature tag"
could be always validated - faking will not work.

Discovery of "feature tag" meaning would be just regular disco#info
request sent to one of clients which announces it. If the result cannot
be validated (MD5 hash doesn't match the namespaces returned) another
client with the same "feature tag" whould be queried.

This would give (in comparision with current JEP-115):

- trafic savings in presence packets (no "version tags")
- trafic savings in querying a client (when the query is required)
- security (no client or server may mask others clients capabilities
  unless it is able to make the same MD5 sum for other set of features)
- there is no problem "what is the core functionality".

- more client queries may be needed if feature-lists often differ. But
  this is not necessary true. 

Server optimizations will still be possible and even simpler (the single
key is the MD5 hash).

Of course MD5 can be changed to any other one-way funciton (eg. SHA).


More information about the Standards mailing list