On Sep 14, 2011, at 16:31, Waqas Hussain wrote: > On Thu, Sep 15, 2011 at 1:37 AM, Matthew A. Miller > <[email protected]> wrote: >> >> On Sep 14, 2011, at 13:40, Waqas Hussain wrote: >> >>> >>> So.. which caps is included in presence? The current exploitable one? >>> Then this doesn't help with preventing poisoning, does it? >>> >> >> the caps hash would be as it is today. So, yes, a client that doesn't >> understand this double-verify would still be vulnerable. >> > > An entity which understood double verify would have the option to > either be vulnerable to poisoning, or participate in IQ floods. It's > this that I'm against. >
Frankly, at this point, I'm starting to think the IQ "flood" would actually be a good thing. It would be a pain point for users and admins, prompting them to get these "untrusted" clients off the network. I also put "flood" in quotes. Let's face it, it would be the early adopters sending all of the requests, and there are policies these clients can implement to help mitigate that. >>> What does considering the result suspect mean? I'm hoping you don't >>> mean it isn't cached. Because that would be much worse than just using >>> a new XEP, which would be a perfectly smooth transition. >>> >> >> Being suspect means it's up to the implementation and deployment. >> * Some might accept (and cache) them but with a log message somewhere. > > Err.... > > So poisoning succeeds. And what happens with these logs? How do you > find the poison needle in the haystack of legitimate messages? I hope > you don't want admins to do this... > Admins that care about the services they provide actually do monitor their logs. Some of them even have found or wrote tools to help this do this stuff already. Client writers that care about their users actually do make sure they can get information such as logs from said users. >> * Some might reject (and not cache) them unconditionally. > > And therefore early adopters are punished with IQ floods... > Actually, it would be the late adopters punished with IQ floods. The early adopters would be contributing to it. >> * Some might put in a timebomb into their implementations that will switch >> from "accepted" to "rejected". > > I just don't like this particular idea... > Just because you don't like it doesn't make it go away. Another possibility is that such implementations perform further heuristics if the results are suspect: * any category or type that contains '/' might be rejected * any result that does not include 'http://jabber.org/protocol/caps' and 'http://jabber.org/protocol/disco#info' as features (not poisoning identities or extensions) is rejected (we should all be doing this anyway; violation of XEPs -0030 and -0115) * any category or type that is empty is rejected (we should all be doing this anyway; violation of XEP-0030) * any feature that looks like a typical identity (e.g. 'client/pc//client name') might get rejected * etc etc >> >>> I have assumed the whole point of all this effort to keep the old XEP >>> is to get rid of the transition period, so if you are not going to >>> cache exploitable caps at all, might as well define a clean new XEP. >> >> The point of trying to keep the old XEP is not to eliminate a transition, >> but to make it less painful. I do think having a complete replacement to >> caps is more painful than applying an addendum or two. As Dave said, the >> building is not burning (yet). >> > > I see. Frankly I was (and still am) confused at what the point was. > > Make it less painful? For whom? > > Less painful for developers? I disagree that adding tons of extra > checks and magic disco features and forms is going to make developers > happy. 1) There haven't been tons. A handful perhaps. 2) this particular idea (discohash form) is something I've talked about with others for different but somewhat related purposes. It might get put into a proposal regardless of where this discussion leads. 3) It does build upon the existing software people have. Someone starting from scratch will have more to do, but frankly they'll have more (IMO, double) to do until any TBD spec has deployed saturation. > A nice clean separate algorithm is much more likely to do that. > When it comes to canonicalization, nothing is clean. Nothing. > Less painful for users/server-admins? Your particular proposal gives > them IQ floods (most of the proposals from stpeter do not have this > issue). The IQ floods are *from* the early adopters, depending on their policies. They also might be as vulnerable as existing clients today, depending on their policies. > > Less painful for spec writers? I don't think so. > This is a non-sequitur. > This is how I see it: > stpeter's proposals: 1. dont succeed in fixing the issue, 2. don't > have the flood issue, 3. don't add anything to presence, 4. complicate > the spec. > your proposal: 1. either doesn't fix the issue, 2. or causes floods, > 3. doesn't add anything to presence, 4. complicates the spec, as both > the current and new algorithms are now part of it. > new XEP: 1. fixes the issue, 2. doesn't cause floods, 3. does add > something to presence during the transition, 4. simplifies the spec. > I have been cautious of adding more to presence (and yes, this TBD spec would add more until everyone implemented it and shut off their existing caps support). A few extra bytes here quickly explodes by many orders of magnitude. From some anecdotal evidence I've seen, it eats up more bandwidth than the floods of a client with buggy caps. > Oh, and I agree there is no burning building. I don't think anyone > thinks there is at the moment. At least that's something. - m&m <http://goo.gl/voEzk>
smime.p7s
Description: S/MIME cryptographic signature
