[standards-jig] Security problems with JEP-115

Joe Hildebrand JHildebrand at jabber.com
Mon Sep 22 04:36:28 UTC 2003


OK, I'm back from Europe, finally.

I agree that the possibility for a client to maliciously give a bad
node#version, and respond with an incorrect set of disco#info is annoying.
I'm not yet convinced it's a full-up "security problem", but let's say for a
moment that it is.

I agree with Jacek in that I haven't been able to think of a meaningful way
to do signing of the information that still meets the requirements.

Doing a bitmask doesn't help that much, since then the registrar has to
maintain a list of bits and their meaning across clients, which seems like a
little much to ask.  Plus, we'd be limited to some wordsize of features.

While I also agree with Justin that querying each user#node#version and
user#node#ext is better than getting an iq:version or a disco from each of
the people on my roster each time I log in or join a room, it still seems
like we can do a little better.

What if we just relaxed the caching language a little, so that querying
based on either user#node#version or node#version is allowed.  If I have
extremely limited storage, and a more trusting soul, I can use the current
approach.  If I've got people on my roster I that I shouldn't, then I can do
more queries.

I guess a couple of more points:
1) client SHOULD NOT respond to requests from those not in my roster.  Note:
requests should not come in from people in the same MUC room, unless the MUC
server has my favorite bug (passing through IQ's).
2) People who inentionally bad results to these disco queries should be
publicly flogged.  Clients SHOULD keep track of where they get results, and
folks who do the more verbose approach SHOULD compare the results to one
another, and only store one copy in the cache.  If a discrepancy is found,
bells, whistles, and cannons should go off, triggering the use of
pitchforks, torches, and firing squads.
3) If said alarm bells ring, the client author can issue a new version, the
offenders account can be cancelled, or their server blacklisted, and anyone
who cares can clear out their cache.

-- 
Joe Hildebrand

 

> -----Original Message-----
> From: Justin Karneges [mailto:justin-jdev at affinix.com] 
> Sent: Sunday, September 21, 2003 4:45 PM
> To: standards-jig at jabber.org
> Subject: Re: [standards-jig] Security problems with JEP-115
> 
> On Sunday 21 September 2003 02:22 pm, Peter G. Millard wrote:
> > Justin Karneges wrote:
> > > Perhaps version strings should be consistent only on a 
> > > per-installation basis, not per-client.  And the string should be 
> > > associated with the JID that sent it, so that one JID 
> cannot speak 
> > > for another.
> > >
> > > 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.
> 
> Well, the original point was to not flood the network during 
> logins or when new contacts become available.  Sure, if we 
> eliminate the client-version optimization, you would end up 
> having to query all 20 of those Psi users, but this would 
> only be a one-time deal.  The 'bulk' of the bandwidth savings 
> would remain, which is that you wouldn't query any of these 
> users again until they upgrade and/or change clients.  Those 
> 19 extra requests that you did on day 1 are of little concern, IMO.
> 
> -Justin
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 



More information about the Standards mailing list