On 6/27/07, Rachel Blackman <[EMAIL PROTECTED]> wrote:
On Jun 26, 2007, at 11:31 PM, Sergei Golovan wrote:
> I think that the XEP must not recommend to cache capabilities based
> only on reported software name and version. The more acceptable index
> is a tuple {jid, client name, client version}.
But that violates the /entire purpose/ of the XEP, and basically
makes it useless.
It would make it useless if everyone used a new client on every new
connection. While someone uses the same client version there's no need
to constantly disco it. So, the aim of the XEP is achieved (for the
higher cost however).
The situation we used to have was that someone would come online, and
other people would disco probe them. Every single resource that came
online. It generated too much traffic, both as you came online and
all your contacts probed you, AND as you had to probe all your
contacts. It was bad. It needed a solution; the solution is, thus
far, this XEP.
But the security flaws are inacceptable for me in this solution.
The purpose of this XEP is to avoid clients flooding stuff by saying
'hi, I am <client> with <version> and <list of extensions>' in a
manner that each of those tokens can be used to cache and reuse the
information. I.e., <client>#<version> and <client>#<extension>
should be unique disco namespaces, and once you have the result you
no longer need to query it each time.
Every couple of weeks we seem to get another set of arguments going
'ZOMG THE SKY IS FALLING PEOPLE COULD TAINT THE INFORMATION CACHE!'
Y'know what? That's absolutely true insofar as it goes... but first,
other than malicious mischief, I'm not certain offhand what such an
attack could actually do to compromise a remote client.
I think that the protocol writer should treat all users and software
developers as some sort of enemies. They make bugs in software, they
constantly do something that violates protocol. Good protocol must not
be vulnerable to this (OK, the software which implements protocol
correctly must not suffer from malicious/buggy software). So, if you
solve some problem, don't introduce other problems.
But second, and more importantly, not one single person has offered a
solution other than 'make every extension hardcoded' or 'just probe
each contact, cache only per-JID,' which returns us to the original
troublesome network-flooding behavior on logins. Both have already
been argued to death here; I'm not going to rehash the arguments.
I guess it's impossible to propose a solution which consumes the same
amount of traffic as current XEP-0115, and cache disco#info separately
for every contact. So, the cost should be higher.
So instead, I'm going to offer a challenge up. The challenge is that
if anyone wants to seriously suggest that caps is a fundamentally
flawed XEP, they should first write up and submit an alternative XEP
for convenient capability discovery and traffic reduction. /PLEASE/
offer an alternative! Come up with some new, more secure XEP.
Suggest a version of caps which requires the client to sign the caps
bit with a private key, thus attempting to prove its identity.
Whatever.
I'd propose another approach. Let every person who writes an extension
to XMPP comes with a reference implementation. It seems to me that
there will be much less forgotten and poorly designed XEPs. Which
would be better for Jabber/XMPP, in my view.
I don't know, nor do I care, what the alternative is; when it's
presented I'll happily assess and potentially implement it, along
with everyone else. But right now, caps is here, it works to solve
an existing problem, and if someone wants to tear it down I suggest
they offer the alternative.
It's time and energy we could spend on sorting out how to make Jingle
more readily implementable. We also have certification and
standardization to think about. And I know I seem to mention this in
darn near every post lately, but we STILL have two incompatible file
transfer specifications live on the network right now unless Google
Talk has decided to implement stream initiation. :)
I don't care much about Jingle now. But a reference implementation
and/or test suite would simplify this work greatly.
Best wishes!
--
Sergei Golovan
