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

[Colm MacCárthaigh]

On Mon, Oct 21, 2013 at 12:17 AM, Paul Vixie <paul at 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