[standards-jig] Security problems with JEP-115
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.
> -----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
> > > 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
> - 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).
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards