On Mon, Oct 21, 2013 at 12:17 AM, Paul Vixie <p...@redbarn.org> wrote: > i apologize for my sloppy wording. i mean full deployment, in either case. > your claims and your proposed workarounds will be evaluated through the lens > of engineering economics. as vernon schryver has been (unsuccessfuly thus > far) trying to explain, effort expended to defend against vulnerabilities > will have to be prioritized alongside of, and in competition with, effort > expended to deploy dnssec.
Economics also include costs. The operational cost of deploying DNSSEC validation on resolvers remains high - there are still frequent key rotation and signing errors that cause various DNS subtrees to be unresolvable. Very few users are willing to accept that that is better for them, which makes it hard to tell the average resolver operator that turning on validation is a good idea. > a correctly functioning recursive name server will not promote additional or > authority data to answers. poison glue in a cache can cause poison > referrals, or poisoned iterations, but not poisoned answers given to > applications who called gethostbyname(). dnssec was crafted with this > principle firmly in mind, and the lack of signatures over glue is quite > deliberate -- not an oversight -- not a weakness. If an attacker can cause the domain to be unresolvable, that seems like a weakness. > thanks for clarifying that. i cannot credit your work in the section of my > article where i wrote about fragmentation, because you were not the > discoverer. in 2008, during the 'summer of fear' inspired by dan kaminsky's > bug, Kaminsky wasn't the discoverer of the "Kaminsky's bug" either, it was long known, yet here you credit him. Not that I mean to deny credit to Kaminsky, he did a good job of publicising the vulnerability. Just as Haya has done here. > your answer is evasive and nonresponsive, and i beg you to please try again, > remembering that the vulnerabilities you are reporting and the workarounds > you're recommending will be judged according to engineering economics. if we > assume that dnssec is practical on a wide enough scale that it could prevent > the vulnerabilities you are reporting on, then your work is of mainly > academic interest. as vernon said earlier today, none of the vulnerabilities > you are reporting on have been seen in use. i also agree with vernon's > assessment that none of them will ever be seen in use. Back before Kaminsky made the need for port-randominsation undeniable with an actual working PoC, this sounds like the ISC/Bind response to port randomisation attacks. Other implementors and operators made a better judgement avoided the problem entirely, taking the cautious path. 5 years later, are you really saying we should ignore another attack vector? The impact even with DNSSEC fully enabled seems concerning enough to warrant attention. -- Colm _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
