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. >> 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... > * Some might reject (and not cache) them unconditionally. And therefore early adopters are punished with IQ floods... > * Some might put in a timebomb into their implementations that will switch > from "accepted" to "rejected". I just don't like this particular idea... > >> 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. A nice clean separate algorithm is much more likely to do that. Less painful for users/server-admins? Your particular proposal gives them IQ floods (most of the proposals from stpeter do not have this issue). Less painful for spec writers? I don't think so. 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. Oh, and I agree there is no burning building. I don't think anyone thinks there is at the moment. > > - m&m > <http://goo.gl/voEzk> > > -- Waqas Hussain
