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

[Vernon Schryver]

> From: Haya Shulman <haya.shulman at gmail.com>

> > I do not see an answer to my intended question. Again, given inevitiably
> limited real time, over-committed programmer and DNS adminstrator
> hours, and limited money, should problems in DNSSEC implementations
> and installations be addressed before or after your issues?

> Some of our recommendations can be useful for security (also against
> other attacks - see earlier email), and can assist with
> interoperability problems, that may emerge during deployment of
> DNSSEC.
> For instance, our recommendations for IP layer, e.g., reducing IP
> defragmentation cache size or randomising IP-ID, can be useful not
> only against poisoning attacks (in particular, fragmentation has a
> long history of exploits for denial/degradation of service attacks);
> Port randomisation is also a useful feature, not only against cache
> poisonig (see earlier email); and so on.

Even if that were correct (it's partly wrong), it would not answer
my question.


> 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 do not think that there is a general answer to this question, as it
> depends on the specific organisation/network.

I guess I'll play a little more by naming three specific outfits.

Should the organizations responsible for BIND, nsd, and unbound to
work on DNSSEC improvements and bug fixes before or after your
issues?  Please do not feel constrained to give a single general
answer for all three organizations but please give 3 specific answers
for those 3 specific organizations.


> Which should be built or fixed first, mechanisms such as auto-signing
> that make DNSSEC easier to deploy and more robust (e.g. reducing
> accidental signature expiration), or your cache pollution issues?
>
> Should requests for proposals and requests for quotes rank DNSSEC
> features including ease of DNSSEC use above or below fixes for your
> cache pollution issues?
>
> Should you spend most of your own time looking for improvements and
> bugs in DNSSEC or looking for more ways to pollute DNS caches where
> DNSSEC is not used?
>
> Both are important: (1) disclosing attacks raises awareness to the
> significance of systematic defenses, and motivates deployment thereof; it
> also enables the networks to protect themselves in the meanwhile. I would
> not be surprised if similar attacks were deployed in the Internet, without
> anyone being aware of their existence.
>
> (2) I also study deployment challenges and improvements (and not only
> attacks).

Do you think anyone sees that as responsive to any of my questions?



> I think that is neither a response to my claim, accurate, nor
> relevant to what I understood of your claim about forwarders.
>
> How can something that introduces a security vulnerability not always
> be a bug in your or anyone's opinion?

> Sure, permissive mode is an explicit feature. I believe a bug is
> something that is not intentionally introduced.... (well, at least not
> as a general rule).

On the contrary, in the real world, any and all computer sins of
commission and many sins of admission are "bugs" according to the
people who matter, users and customers.  The programmer, vendor, or
whatever can sometimes escape censure by pointing at a specification,
but even when it works, that tactic never wins respect, friends, or
more business, and it can lose old business.


> If you meant instead to say that permissive verification is a less
> important bug that other things, then how do you rank your cache
> pollution issues against other bugs starting with not deploying DNSSEC?

> I would hope that disclosure may help some organisations and networks
> protect themselves. The other option is to be unaware of the
> vulnerabilities (and their exploits).
> Do you think vulnerabilities are better left for attackers to take care of?

That implication that I have ever said or suggested that you should
not have published your findings is disingenuous and offensive.

My problem with your findings is that your are grossly overstating
their significance.  None of them will ever be seen in the wild.  As
As http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 and
as I've said, showing the inevitiable weakness of port randomization
is good.


>  BTW, we withheld some of the works from publication, and tried to
> coordinate disclosure.

That is the right thing to do except when exploits have already
been seen in the wild or are likely to be seen soon.  However, given
the practical certainty that none of your vulnerabilities will ever
be seen in the wild, no one should have complained if you had not.


> Your work would be valuable if it helped pressure people to get
> busy on DNSSEC.  However, instead of saying "Use DNSSEC because
> port randomization has these newly discovered weaknesses", you only
> grudgingly and under pressure admit that DNSSEC even exists.
>
>  Many networks cannot deploy DNSSEC overnight, due to different factors.
> Port randomisation algorithms that were proposed have weaknesses, but
> proper randomisation should solve these problems.

I doubt the implication in that sentense, because I give you more
credit than to think that any of the recommendations in your 19 Oct 2013
mail could and would be deployed "overnight" or easier than DNSSEC by
any except a very few individuals.  The only recommendation that might
be done quickly is forcing TCP to proxies.  That could be done with a
firewall ACL against UDP, but no one should do that.  The others require
changes to source.  For example, several of your recommedations are
to "randomise ports."  Any code that doesn't already do that will
continue not doing it at least until its next release.

Fixing your vulnerabilities would be technically easy for many people,
including those whose resumes are like mine.  However, what is easy
for professional kernel and DNS server hacks is irrelevant.


> I was under pressure to catch a flight when I responded and forgot DNSSEC;
> it is as dear to me as it is to you :-)

I'm sorry, but I think the mention of DNSSEC in your paper exists only
because others forced it.  I'm forced to that belief by various things
including your refusal admit the obvious about relative priorities and
by statements like that sentence above that suggests that fixing port
randomization could be easier than deploying DNSSEC in any except quite
exceptional cases.

You directed Paul Vixie to a copy of your paper on your web site, but
I didn't see a URL.  Is http://www.ec-spride.de/ your web site and if
so, is your paper there?  I can't find any other likely URLs.


Vernon Schryver    vjs at rhyolite.com