OK, as one of the authors of the JEP in question, I do have the responsibility so say this at least one more time, I suppose. I may not have done it on the jdev list, but I thought I'd gotten the gist across in foundation meetings.
I realize that there are security holes in JEP-0025. I'm not convinced that any of the solutions that have been proposed are the "right" solution. I think we need to have a discussion about it. I think the way to do that is to have a new, standards-track JEP. Yes, it would be nice if I could get around to doing that, but I've been fairly swamped. If someone else could take a crack at a strawman, it would be helpful. Next, there *is no way* for me to modify our current product in the timeframes involved, due to our existing release cycle. Once we have a standards-track JEP approved, we'll see if we can support it in a future version. Because of this, it makes no sense to modify JEP-0025 to add any security measures. So, the foundation needs to choose one of these: 1) I can withdraw the JEP, in which case there will be no public documentation of the polling protocol. That doesn't seem neighborly to me, but I'm willing to bow to overwhelming pressure. Remember, it's INFORMATIONAL, which means that it documents an existing protocol. 2) Leave it as is. The council can decide whether or not to approve it. For informational JEPs, I think the criterion should be "does this JEP accurately portray the existing protocol." If the council decides that the criteria should include "... and we like it," then the council should reject it. If that happens, I don't know if it should stay on the JEP list or not. That's a process question. 3) Same as 2, but add some big bold letters that say "THIS PROTOCOL IS INSECURE. ITS USE IS DISCOURAGED." Frankly, I'm fine with that. I'd like to see more people document protocols that they are using as informational, to at least seed the discussion of what ought to be a standard. I'm concerned about the potential precedent of discouraging that behavior. <rant direction="aside"> As I've said to a couple of people, I think that HTTP polling is a security nightmare, no matter how it's implemented. I've basically enabled people to thwart their firewall administrators. Yes, it's useful for those situations where the firewall is administrated by people that don't believe that the Internet can be used for legitimate business purposes, so we have to have it in our product mix. But its use should be discouraged where possible. </rant> <note relevance="low"> I believe that if you do your polling over HTTPS, none of the stated attacks are possible, as far as I know. There are still some cool traffic analysis attacks, but no more so that with any Jabber session. If you have enough hardware to do HTTPS polling for a large number of users, well... wow. That's impressive, I'm sure. </note> > -----Original Message----- > From: Michael F Lin [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 12:52 PM > To: [EMAIL PROTECTED] > Subject: Re: [JDEV] Implementation of JEP-0025 (Jabber HTTP Polling) > > > 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" | > | | <[EMAIL PROTECTED]| > | | > | > | | Sent by: | > | | jdev-admin@jabber| > | | .org | > | | | > | | | > | | 06/06/2002 01:05 | > | | PM | > | | Please respond to| > | | jdev | > | | | > |---------+----------------------------> > >----------------------------------------------------------------------- > -------------------------------------------------------| > | > | > | To: <[EMAIL PROTECTED]> > | > | 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 > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > > > > > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
