[Council] new JEP -- position paper needed!
mikelin at MIT.EDU
Tue Apr 2 01:11:05 CST 2002
Here is my stream-of-thought for the kind of ideas that would go into a
position paper, at least from my perspective. Joe and Craig, I would
really like your input on these points, because I don't doubt that some
of my concerns might simply be a result of my misunderstanding.
"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.
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, I won't argue
directly against this hack, but if my conjecture is correct (or even if
it's incorrect) it would be useful to clarify this point in the JEP.
Also wouldn't it make more sense to return transport errors in the HTTP
response code instead of an overloading of the session ID?
"The best solution for sites that are concerned about security is to run
their own Jabber server, either inside the firewall, or in a DMZ [1 ]
network. Failing that, allowing internal clients to access external
Jabber servers poses less risk today than most email access methods,
such as POP3."
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.
And now that you mention POP3, it seems to me it might actually work
quite nicely to base a proxied protocol on Sendmail/POP3 instead of HTTP
(assuming proxies open 25 and 110 as well as 80, which I understand
might not always be the case, but bear with me for this thought
experiment). Security aside for a moment, this would be very nice
because this pair of protocols is already designed for the kind of
polling we are trying to do, albeit more slowly. We could even, if we so
chose, rather elegantly build framing into the protocol by putting each
packet into its own "e-mail". Now as for security, clearly POP3 is
pretty bad because it transmits the password in cleartext. But so long
as we are only looking to trick a proxy server, we could modify the
semantics of our protocol, such that the password sent in each request
is a cryptographic hash of the user's password and some request sequence
number, as I described before.
Finally, I would like to see more specifics about your implementation.
In particular, some suggested polling intervals might be helpful (1Hz?).
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.
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