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

[Vernon Schryver]

> From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <colm at stdlib.net>


> 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.

On what do you base your claims about the fatal costs of DNSSEC
validation?
I claim relevant knowledge and experience, not just from code I wrote
a few years ago to reduce the costs of DNSSEC on very large resolvers,
but from signing my own domains and enabling validation on all of the
resolvers that I control.  My domains and resolvers are insignificant,
but I hope I would have noticed any fatal costs.

Are you aware that Comcast's resolvers have been validating for some
time?  I think Google is also validating based on a "Webmaster, your
web page is not available to your spider" messages after a configuration
error in my signing machinery, but am not sure.  Does that conflict
with your claims about the fatal costs of validating?

Yes, I've noticed that Google is still not signing.  Maybe the
continuing hijackings of their ccTLD domains will move them.


> If an attacker can cause the domain to be unresolvable, that seems
> like a weakness.

True, but the right question is not "Does DNSSEC add vulnerabilities?"
but "Overall, is DNS more or less secure with DNSSEC?" or "Among all
of the things I can do, what will improve the security of my users and
the Internet in general?"

Defenders who care about the security of their systems and the Internet
in general don't pick and choose among weaknesses based only on what
is easiest, what can be punted to others, or what contributes to their
reputations.  They don't do as Steve Gibson did and harp on the bogus
catastrophy of Windows XP raw sockets to enhance his reputation and
sell his services.


> 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.

I suspect Kaminsky got the credit because he had been contributing to
the field for years.  But who cares who got there first?  Every request
I see for credit is recorded in my private accounting as a debit against
the credibility of the person demanding credit, because credit demands
suggest interests which suggest biases and so inaccuracy.

Yes, I've heard of Kaminsky's business interests, and so I don't
take his announcements at face value.  You should also discount my
credibility based on my pecunary or other interests.  Where you
can't determine my interests, act on your best guess.


> 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?

Who besides you and Haya Shulman has said anything about not randomizing
ports?  What port randomization improvements do you think are needed
in current releases of any major DNS implementation?  Where port
randomization problems exist such as in junk CPE that won't get fixed
before I retire, what contributes most to solutions, selling 
$29.95/#24.95/£19.95 academic papers or turning on DNSSEC?

The issue for me is one of relative priorities.  Among all Internet
security issues that I might touch, which should get my attention
and effort?  By remaining silent about emphasising port randomization
over DNSSEC (or using distant instead of nearby validating resolvers)
would I help or harm?


> The impact even with DNSSEC fully enabled seems concerning enough to
> warrant attention.

Let's agree that ports ought to be as random as TCP ISNs, improve port
randomness where each of us can, and stop implying that anyone thinks
or says otherwise.  Let's also stop the "DNSSEC is a problem" stuff.

Finally let's consider how you are helping.  Is there anything you can
do to improve port randomization?  If you are committer in any open
or proprietary source trees, will you make any needed port randomization
fixes?  Have you deployed DNSSEC?  What about BCP 38, since cache
poisoning is likely to depend on BCP 38 violations?


Vernon Schryver    vjs at rhyolite.com