[Council] new JEP -- position paper needed!

Craig ckaes at jabber.com
Tue Apr 2 10:32:00 CST 2002

Comments interspersed.

Mike Lin wrote:
> "In some browser/platform combinations, sending cookies is not possible
> due to design choices (bugs?) in the browser. Therefore, a work-around
> was needed to support these platforms."
> I presume the "work-around" this refers to is the sending of the Session
> ID in the payload of the request instead of in a standard responding
> cookie header. If so, this should be stated more clearly.

That is precisely what it is referring to.

> I don't quite understand how the browser is relevant here. Why is the
> web browser's (a UI) ability to send cookies relevant to the design of a
> Jabber client? Recalling that this JEP describes the JabberIM
> implementation, one might conjecture that your implementation uses
> WinInet or some other prepackaged HTTP component which does not like the
> cookie header. Again, since this JEP is informational, 

JIM does not support HTTP polling.  Our webclient does. 
(http://www.jabber.com/products/web.shtml).  One can think of an HTTP 
protocol for jabber as a facilitator towards implementing a web client 
architecture.  From there it is a hop step and a jump to implementing 
the client in a browser.  Given that, it would be nice to support IE, 
which most polls put as what ~90% of those using the internet are using. 
  It swallows cookies.  Hack or not, nobody in their right might would 
choose to exclude 90% of the available market for aesthetics.

> Also wouldn't it make more sense to return transport errors in the HTTP
> response code instead of an overloading of the session ID?

These are limiting in their richness.  Most errors would fall into 
"Unexpected Server Error."  The errors that we've chosen allow for much 
greater precision.  Jabber != Apache.

> Unless there is something I am flagrantly overlooking (which is
> certainly possible), this protocol is rather obviously vulnerable to
> hijacking by an eavesdropper, in an attack much easier to achieve than a
> similar attack against a single long TCP connection. Admittedly, our
> existing security over such a connection leaves something to be desired,
> but this protocol seems to me to leave much more.
> I would *strongly* recommend, even though this is an informational JEP,
> adding some kind of mediocre session authentication by means of a
> crytpographic hash over the user's password and a request sequence
> number of some sort. I think there are very cheap ways to at least bring
> the security of this protocol basically on par with what we have now.

Unless you do this for every poll request, you're not avoiding the 
hijacker.  And if you're doing this with every packet, not only are you 
taking on tremendous overhead, you are providing many many opportunities 
to snag your username/password.

Nothing is preventing digest or 0k authentication.  Over SSL.  While I 
admit that this may not be an adequate solution for the department of 
defense (Note: IANAL), it has proved sufficient for any number of 
financial applications.

> Finally, I would like to see more specifics about your implementation.
> In particular, some suggested polling intervals might be helpful (1Hz?).

At least 10Hz ;-)

Just kidding.  We've seen it scale very nicely with 1 second polling 
intervals for as may as 2000 simultaneous connections.  For greater 
numbers of users, increase the polling interval.

> It seems that several points in the protocol besides those I pointed out
> are a result of the specific needs of JabberIM, written in Delphi (I
> think) on Win32. For example "Both the request and response bodies are
> UTF-8 encoded text, even if an HTTP header to the contrary exists." I
> would like to see these clearly pointed out as a requirement of your
> implementation and not necessarily of an engineered design.

Like I said, JIM does not support HTTP polling.  Try out our web client.

> Thanks,
> Mike
> On Mon, 2002-04-01 at 15:46, Peter Saint-Andre wrote:
>>OK, we're going to try this new process. I have several JEPs in the queue
>>that I will endeavor to release to the Council in the next few days. The
>>first one is here:
>>I am giving these JEP numbers since it's easier for me to keep track of
>>them that way, however I will not release this for general discussion and
>>review until after we've written our position paper. So have a look at the
>>JEP and makes some comments to the list here, then we'll find someone to
>>put together our comments into a position paper.
>>Have at it!
>>Peter Saint-Andre
>>email+jabber: stpeter at jabber.org
>>weblog: http://www.saint-andre.com/blog/
>>Council mailing list
>>Council at jabber.org

More information about the Council mailing list