[JDEV] Implementation of JEP-0025 (Jabber HTTP Polling)
Michael F Lin
MFLIN at us.ibm.com
Thu Jun 6 13:52:24 CDT 2002
I agree, unfortunately, we now have a new implementation based on this
"informational" JEP which is vulnerable to the same security problems. So I
propose that the informational vs. standards track distinction is pretty
meaningless. Look at Matthias' comments - he used it for lack of anything
better.
The authors of this JEP, in my opinion, have the responsibility of fixing
it. We have handed them several ways to do so. Jabber, Inc., in my opinion,
has the responsibility of fixing its web client before its users using it
for "financial applications" get burned.
-Mike
|---------+---------------------------->
| | "Peter Millard" |
| | <me at pgmillard.com|
| | > |
| | Sent by: |
| | jdev-admin at jabber|
| | .org |
| | |
| | |
| | 06/06/2002 01:05 |
| | PM |
| | Please respond to|
| | jdev |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: <jdev at jabber.org> |
| cc: |
| Subject: Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling) |
| |
| |
>------------------------------------------------------------------------------------------------------------------------------|
Mike -
> I agree, and I strongly recommend against the use of JEP-0025 as-is
> for any remotely sensitive purposes.
>
> We have been aware of the security problems for two months and have
> proposed multiple viable solutions, but nothing has been fixed. This
> JEP either needs to be fixed or withdrawn.
*disclaimer: I am employed by Jabber, Inc* :)
JEP-25 is INFORMATIONAL! It won't be withdrawn as it's not standards track.
The whole idea behind informational JEPS is that they allow companies (like
Jabber, Inc.) to document the protocol extensions that they build, so other
people in the jabber community can use and build other products to them (if
they so desire). It's unlikely that this JEP will change since it reflects
a
currently deployed product (good bad or ugly :).
Someone needs to take JEP-25 as a base, and create a new STANDARDS track
JEP
that fixes the security holes in the current implementation and submit it.
Then client authors (like myself) can choose to implement either JEP-25,
the
new standards JEP, or both.
Hope this makes sense.
Peter M.
_______________________________________________
jdev mailing list
jdev at jabber.org
http://mailman.jabber.org/listinfo/jdev
More information about the JDev
mailing list