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

Sun Oct 20 22:53:51 UTC 2013

>
> i interpreted your answer to my question as "no", since every

counter-example you cited was a case where dnssec was used improperly.
most importantly, the lack of signed delegations and signed glue is by
design, and is not a weakness in dnssec, since the only remaining
vulnerability is denial of service, of which there are many other (and

easier) methods.
>

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`.

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.

 i'd have to read your published work before i could cite it. can you

tell me where to find it online, outside any paywall or other
restrictions? note that i'll be happy to respond, with citations, since

your work is so topical.
>

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.

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.

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.

>
>

On Sun, Oct 20, 2013 at 10:01 PM, Haya Shulman <haya.shulman at gmail.com>wrote:

> 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
>

-- 

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/20131021/8a721640/attachment.html>