> From: David Conrad <d...@virtualized.org> > > Should the people working on DNS implementations prioritize making > > their DNSSEC code more robust and easier to use above or below > > addressing your issues? > > I'd say "below". > > Resolver operators (hopefully) want to protect their caches. DNSSEC = > will do that, but only if people are signing their zones. There are lots = > of external parties (e.g., registries, registrars, software developers, = > resolver operators, etc) to get DNSSEC deployed and there remains very = > little incentive for anyone to sign their zones, regardless of how = > robust and easy it might be made. > > The alternative would be to disregard current and future cache poisoning = > attacks. Pragmatically speaking, I personally think it highly = > questionable to ignore cache poisoning vulnerabilities because something = > which isn't yet deployed to 10% of the Internet will fix it. > > This would be a bit like saying "don't deploy RRL because BCP38 is the = > correct answer to the problem".
On the contrary, anyone who spends even one minute on RRL that could be spent on BCP 38 should be...well, I can't say "shot" because I oppose capital punishment. RRL should be considered only after everything possible has been done for BCP 38. Similarly, only after there is nothing that you can do improve your DNSSEC implementation should you consider improving your port randomization. I agree that port randomization should come before a lot of other things, although that's not saying much because the major DNS implementations are filled with things I would have vetoed if I'd been king. I think their work showing the weaknesses of port randomization in theory and practice is important, because it shows that no security should depend on adversaries being unable to inject packets into UDP or TCP streams because ports are secret. I strongly disagree with Haya Shulman's words to Paul Vixie that seemed to say that their work might fix other applications and protocols. I think their work shows that port randomization is like RRL, a lame kludge of a mess that is better than nothing but not even a distant second choice to actually fixing the problem. I say only "consider improving port randomization," because nothing should be added to anything or even changed without clear and significant benefits, especially in security related areas. You've been around long enough to remember many added "nice" features caused big security problems. Vernon Schryver v...@rhyolite.com P.S. I'm licensed by http://ss.vix.su/~vixie/isc-tn-2012-1.txt and http://ss.vix.su/~vjs/rrlrpz.html to criticize RRL. P.P.S. I've often heard Paul say much the same thing about RRL being a bad idea except compared the alternative of ignoring the consequences of everyone else's failure to deploy BCP 38. _______________________________________________ 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