[standards-jig] Security problems with JEP-115

Joe Hildebrand JHildebrand at jabber.com
Mon Sep 22 20:02:19 UTC 2003


Why couldn't I just send a MD-5 that matches the bad info that I was about
to give out?  How is that any different than what we have now?  It would
have to be PKI-signed to get any added value out, and that raises an
entirely different set of issues.

-- 
Joe Hildebrand

 

> -----Original Message-----
> From: Jacek Konieczny [mailto:jajcus at bnet.pl] 
> Sent: Monday, September 22, 2003 12:56 AM
> To: standards-jig at jabber.org
> Subject: Re: [standards-jig] Security problems with JEP-115
> 
> 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):
> 
> pluses:
> - 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".
> 
> minuses:
> - 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).
> 
> Greets,
> 	Jacek
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 



More information about the Standards mailing list