{5} Assigned, Active Tickets by Owner (Full Description) (2 matches)

Evil authoritative servers can select such a high number of iterations that resolvers are overwhelmed. The proposal is to allow resolvers to specify an upper limit for iterations that it will accept and if a response has a higher number the resolver will treat is as bogus. Olafur Gudmundsson asked why we can't get rid of iterations and just use the salt. Ben explained that the iterations are designed to increase the cost of a dictionary attack, while the salt is used to increase the cost of a pre-computed dictionary attack. Olafur rephrased his question to is the salt sufficient for the threats people are seeing? Ben feels this is no, as a single iteration is very easy to handle with a network probe. Olaf expressed a concern that leaving this up to resolvers will cause some resolvers to set a low number and some a high number causing a zone to appear secure or bogus to different resolvers. Ben answered that by picking a sufficiently high number this shouldn't be a problem. It should be a single number and not in the draft. Mike St.Johns said that if a number is going to be chosen, please put it in the draft and be nice to implementors and users, don't make it configurable, just set it across the board. Ben says if the working group feels strongly about this it will be done. Someone asked if a mechanism could be added such that parent zones can set limits for the iterations. The room response was highly negative.