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

[Haya Shulman]

Sorry for delay, I was omw to a different continent.
Please see response below.


On Sat, Oct 19, 2013 at 9:21 PM, Paul Vixie <paul at redbarn.org> wrote:

> Haya Shulman wrote:
>
> You are absolutely right, thanks for pointing this out.
>
>
> thanks for your kind words, but, we are still not communicating reliably
> here. see below.
>
>
>  DNSSEC is the best solution to these (and other) vulnerabilities and
> efforts should be focused on its (correct) adoption (see challenges here:
> http://eprint.iacr.org/2013/254).
> However, since partial DNSSEC deployment may introduce new
> vulnerabilities, e.g., fragmentation-based attacks, the recommendations,
> that I wrote in an earlier email, can be adopted in the short term to
> prevent attacks till DNSSEC is fully deployed.
>
>
> by this, do you mean that you have found a fragmentation based attack that
> works against DNSSEC?
>
> One of the factors, causing fragmentation, is signed responses (from zones
that adopted DNSSEC). Signed responses can be abused for DNS cache
poisoning in the following scenarios: (1) when resolvers cannot establish a
chain-of-trust to the target zone (very common), or (2) when resolvers do
not perform `strict validation` of DNSSEC. As we point out in our work,
many resolvers currently support such mode (some implicitly, others
explicitly, e.g., Unbound), i.e., signal support of DNSSEC, however accept
and cache spoofed responses (or, e.g., responses with missing or expired
keys/signatures).
According to different studies, it is commonly accepted that only about 3%
of the resolvers perform validation. One of the reasons for support of
permissive DNSSEC validation is interoperability problems, i.e.,
clients/networks may be rendered without DNS functionality (i.e., no
Internet connectivity for applications) if resolvers insist on strict
DNSSEC validation, and e.g., discard responses that are not properly signed
(i.e., missing signatures).

Our attacks apply to such resolvers. Furthermore, many zones are
misconfigured, e.g., the parent zone may serve an NSEC (or NSEC3) in its
referal responses, while the child is signed (e.g., this was the case with
MIL TLD).

 by this, do you mean that if DNSSEC is widely deployed, your other
> recommendations are unnecessary?
>

Some of our recommendations are still relevant even if DNSSEC is widely
deployed. We showed attacks that apply to properly signed zones and
strictly validating resolvers. Since referral responses are not signed, the
attacker can inject spoofed records (e.g., A records in glue) which will be
accepted by the resolvers. Such cache poisoning can be used for denial (or
degradation) of service attacks - a strictly validating resolver will not
accept unsigned responses from the attacker and will be stuck with the
malicious cached name server records (unless the resolver goes back to the
parent zone again - however such behaviour is not a security measure and
should not be relied upon).

Furthermore, in the proxy-behind-upstream setting, even when DNSSEC is
supported by all zones and is validated by the upstream forwarder, but not
by the proxy, the proxy can be attacked. Ideally validation should be at
the end hosts - we are not there yet with DNSSEC.


> in your next message you wrote:
>
> Haya Shulman wrote:
>
> ..., the conclusion from our results (and mentioned in all our papers on
> DNS security) is to deploy DNSSEC (fully and correctly). We are proponents
> of cryptographic defenses, and I think that DNSSEC is the most suitable
> (proposed and standardised) mechanism to protect DNS against cache
> poisoning. Deployment of new Internet mechanisms is always challenging (and
> the same applies to DNSSEC). Therefore, we recommend short term
> countermeasures (against vulnerabilities that we found) and also
> investigate mechanisms to facilitate deployment of DNSSEC.
>
>
> in 2008, we undertook the short term (five years now) countermeasure of
> source port randomization, in order to give us time to deploy DNSSEC. if
> five years made no difference, and if more short term countermeasures are
> required, then will another five years be enough? perhaps ten years?
> exactly how long is a "short term" expected to be?
>
> for more information, see:
>
>
> http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/
>

Thanks, you summarised this very nicely. I'd like to bring it to your
attention that, in contrast to other sections, you did not cite our work
explicitly, in a section where you describe our fragmentation based attacks
(please add it).
My response to your question is the following: DNSSEC is a new mechanism,
crucial for long term (future) security of the Internet. The concern that
you are raising applies to other new mechanisms as well, e.g., BGP security
and even IPv6, and is not specific to DNSSEC. Deploying new mechanisms in
the Internet has always been a challenge, and the mechanisms may go through
a number of adaptations during the incremental deployment phases, and
intermediate transition mechanisms may be designed. I believe that five
years is not a significant time frame in terms of the future of the
Internet. So, IMHO it may be the case that further countermeasures may be
required.

BTW, port randomisation prevents a number of attacks (not only cache
poisoning) and so is useful even when DNSSEC is fully deployed and
validated.

>
>
> vixie
>


Best Regards,

-- 

Haya Shulman

Technische Universität Darmstadt****

FB Informatik/EC SPRIDE****

Morewegstr. 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/20131020/2ec7e516/attachment.html>