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

[Haya Shulman]

> I notice that besides not answering the priority question, you also
> did not say where we can read your paper to see whether you mention
> DNSSEC only as a coerced afterthought.


@*Vernon Schryver *
Please read my first post in this thread, you should find all information
there.


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.

@*Vernon Schryver*

Requiring such answers from me is absolutely out of place, I am
probably not aware of the constraints that organisations face in their
every day operation of the Internet, and so I never argued which
coutermeasures must be deployed and by whom. My goal is to identify
vulnerabilities and investigate and recommend countermeasures that can
prevent them. Each organisation should decide what solution suites its
needs best, based on this and other information that is available to
it.

It is also ironic that especially those that emphasise their own credit,
experience, and reputation, and even use it to justify and back-up their
arguments (i.e., `proof-by-intimidation` :-)), are so negligient to the
work of others. Such a conduct can do more damage to the community than
good. I hope that this is only a misunderstanding...

---

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.


@*Paul Vixie*
BTW, when we shared this attack with you, after some correspondence where
we explained the details, you wrote to us admiting that it was different
from the vulnerability that Florian discussed with you (I can forward that
email if you prefer).
But, irrespectively, even if it was suggested that fragmentation poses a
vulnerability (and indeed it has a long history of attacks) - there is a
difference between suggesting something and actually doing it (there are
different pieces that need to be put together). Had there been a source
where this attack was described, I would have of course cited it, this is
the only ethical thing to do.
As I wrote in an earlier email, port randomisation vulnerability was
identified long ago by Bernstein, and yet Paul Vixie (justly) credits Dan
Kaminsky for putting the pieces together. Of course Dan deserves the credit
- putting it all together requires research and work. So, I look forward to
seeing this fixed.

---


> On what do you base your claims about the fatal costs of DNSSEC
> validation?


@*Vernon Schryver*
There are significant research efforts targeted at identifying deployment
problems and providing recommendations, e.g., see recent work published at
USENIX'13:
http://cseweb.ucsd.edu/~hovav/papers/lrss13.html

This work performed a study of DNSSEC deployment and also quantified
failures that validating resolvers experience. You may find it relevant.
Trying to ignore or deprecate such research, and discussions thereof, and
employing `proof-by-intimidation` arguments, will not benefit this
community.


---

 I for one, do not believe DNSSEC is any difficult. I have turned DNSSEC
> wherever I can. It has become easier and easier in the past few years to
> the point I would call deploying DNSSEC today trivial.


*@Daniel Kalchev*
Of course there are networks that may not have problems, this is not the
_question_, the challenge is related to those that cannot for some reason,
or are not motivated to do so. It is great that there are experts such as
yourself that can quickly and easily adopt DNSSEC. But as you know Internet
is composed of different networks, and there are organisations and networks
of different size and with different dependencies and constraints, so, I am
afraid that the fact that you found it easy to deploy DNSSEC and do not
experience problems with it, does not constitute a general proof :-)


Disclosing such potential vulnerabilities remains valuable work, but I
> think careful consideration needs to be applied to the engineering
> economics of the best operational-world mitigation approaches.


---

@*Keith Mitchell*
I do not advocate to deploy these or other countermeasures. Above any doubt
you are in the best position to decide which countermeasures to deploy. I
am probably not aware of some of the constraints that organisations face in
their every day operation of the Internet, and so I never argued who should
deploy what. We identify problems and provide recommendations explaning why
they may prevent the problems.
The situation with DNS checkers is different from deployment of port
randomisation.  DNS checkers is a very important service to the community
and the efforts that their operators took to make them available is very
valuable.
However, an illusion of security is more dangerous than not being protected
at all (in the later case one is aware that he is not protected and may be
attacked). Clients rely on such reports for their security.
I admit that I do not know what economic effort is required to patch DNS
checkers which report per-destination ports, recommended in [RFC6056], as
secure, but I suggested a fix to this vulnerability some time ago, that
should be fairly simple to implement; the problem with the porttest checker
is that each IP address of the checker system receives a single query from
the tested resolver, and so to each such IP address a random port is
selected. But, if more than a single query were sent to each checker IP
during the test, then the predictable sequence would be easily identified.

---

Port randomization is an extremely thin reed for security, because
> there are so few port number bits.


@*Vernon Schryver *
There are techniques to artificially inflate ports' distribution, and we
already described one technique in ESORICS'12 paper.

---

I am glad to see that there is interest in our work, and that it triggers
such elaborate discussion.
The stressed responses by some make me wonder if it may be the case that
some would prefer that these attacks stayed hidden from the public eye -
and since I am generally against security by obscurity and proofs by
intimidation, this actually encouranges me to continue the research on DNS
security, and in particular to study the practicality of the
vulnerabilities :-)

Which brings me to the topic of resolver-behind-upstream attacks which were
not commented upon.
As you know, one of the recommendations of experts and Internet operators,
following Kaminsky attack, was `either deploy patches or configure your
resolver to use a secure upstream forwarder`, e.g., OpenDNS was typically
recommended. The security is established since the resolver is hidden from
the Internet and sends its requests only via its upstream forwarder.
This configuration is still believed to be secure and is recommended by
experts.

 As you know we found vulnerabilities in such configuration, and designed
techniques allowing to find the IP address of the hidden resolver, and then
to discover its port allocation (the attacks apply to per-destination ports
recommended in [RFC6056] or to fixed ports).
This attack can be extremely stealthy and efficient, and applies to
networks where communication between the resolver and upstream forwarder is
not over TCP, and therefore can be fragmented (fragmentation of a single
byte suffices).
 We also confirmed with measurements that this vulnerability applies to a
large fraction of neworks that use upstream forwarder. Some may claim these
networks are probably not security aware in the first place and are anyhow
vulnerable to other attacks.
However, this is not so, among the vulnerable networks there are `security
aware` networks, that use this configuration and offload recursive resolver
services to dedicated third parties, since it is recommended by the experts
and is believed to be secure. In particular, the upstream forwarder is
often even validating DNSSEC, and is operated by a dedicated organisation,
that provides proprietary services of secure upstream forwarding only to a
limited number of networks.

The problem is that operators of these networks believe to have deployed
all the required countermeasures and protected themselves from attacks,
while they may be vulnerable to attacks.
Please see paper for more details and a brieft abstract in the first
message on this thread.


-- 

Haya Shulman

Technische Universität Darmstadt****

FB Informatik/EC SPRIDE****

Mornewegstr. 30****

64293 Darmstadt****

Tel. +49 6151 16-75540****

www.ec-spride.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131022/b408bf5d/attachment.html>