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

[Paul Vixie]

Haya Shulman wrote:

> I understood that you asked two questions:
> (1) by this, do you mean that you have found a fragmentation based attack
> that works against DNSSEC?
> (2) by this, do you mean that if DNSSEC is widely deployed, your other
> recommendations are unnecessary?
>
> --
>
> Correct me if I am wrong, but I understood
>
> that in (1) you meant partial deployment of DNSSEC, since later in (2)
> you emphasised the `full deployment`.

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.

> As I wrote, even if DNSSEC is fully deployed and validated,
> denial/degradation of service attacks, via cache poisoning (of records
> in referral responses), are still feasible - since the resolver caches
> spoofed records. DNSSEC was designed to prevent cache poisoning.

your text above shows a drastic misunderstanding of both dns and dnssec.

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.

> ...
> This is the work that we shared with you last year, when we contacted you
> regarding help coordinating disclosure of the fragmentation-based
> vulnerability. You also cite it at the end of the article, but it is not
> mentioned explicitly in the fragmentation section. The publication version
> of this work is on my site.

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, i was a personal information hub among a lot of the dns
industry. at one point florian weimer of BFK called me with a concern
about fragmentation related attacks. i brought kaminsky into the
conversation and the three of us brainstormed on and off for a week or
so as to how to use fragments in a way that could cause dnssec data to
be accepted as cryptoauthentic. we eventually gave up, alas, without
publishing our original concerns, our various theories as to how it
might be done, and why each such theory was unworkable.

i was happy to cite your work in my references section because your
explaination is clear and cogent, but since you were not the discoverer,
i won't be crediting you as such.

> [vixie]
>> i believe that if we can't make a significant difference in the
>> resiliency and quality of core internet infrastructure after 16
>> years, then we wasted our time. and i know that if five more years
>> wasn't enough, then fifty years would also not be enough. as an
>> industry we must at some point either declare victory and stop
>> creating lower quality counter-measures which add complexity, or we
>> must declare failure and stop expecting dnssec to help with any
>> problems we might discover in the existing system. we can't
>> realistically or credibly have it both ways. 
>
> I beg to differ, I think DNSSEC is already a success. Maybe, had DNSSEC
> been immediately fully adopted as soon as it was standardised, in 1997, it
> could have, by now, been adandoned due to interoperability, functionality
> and security problems that would have emerged (nothing specific of DNSSEC
> but just the same for any new mechanism).
> Since changing the Internet and adapting it for DNSSEC is not a realistic
> option, DNSSEC had to be adapted. DNSSEC has already substantially changed
> over the years, during its incremental deployment.
>
> IMHO deploying additional countermeasures, like port randomisation,  in
> tandem with DNSSEC, in the meanwhile, does not introduce a security or
> functionality problem.

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.


> [vixie]
>> i'd like to hear more about this. at the moment i have no picture in
>> my head of "not only cache poisoning" when i think of the prevention
>> offered by source port randomization. 
>
> Port randomisation can be a useful coutermeasure against other attacks as
> well, e.g., the ability to predict ephemeral ports can be used for a range
> of attacks, e.g., name server pinning (not only for poisoning, e.g., for
> covert communication), low rate attacks against clients/resolvers,
> breaching instances' isolation on cloud platforms, injection of content
> into TCP connections (was applied by Watson VU415294 against BGP, but can
> also be used against web traffic), deanonymisation of communication over
> TOR. Some of the papers are already on my site.

that's too many "e.g.'s" and external references for me to follow. each
fragmentary concept you've listed above strikes me as a nonsequitur for
source port randomization. can you dumb it down for me, please?

vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131021/47a3cf9b/attachment.html>