[dns-operations] summary of recent vulnerabilities in DNS security.

[Vernon Schryver]

> From: David Conrad <drc at 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    vjs at 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.