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

Sun Oct 20 23:42:07 UTC 2013

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

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.

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

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

---

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?
 BTW, we withheld some of the works from publication, and tried to
coordinate disclosure.

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

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

>  In that case, on what should an organization spend time or money
>
> first, on DNSSEC or the recommendations in the mail message?  Would
> it be better if each of the recommendations in the mail message
> started with something like this?
>
>     Deploy DNSSEC, and consider the follow to help protect cached
>
>     data not yet protected with DNSSEC.
>>
>
>
> It's a good point, thanks. I will rewrite the recommendations according to
> what is essential and also against which type of attack and to what network
> configuration it applies.
>
>
> That sounds like a more significant bug than port obscurity or
>
> randomization.  If it is a bug, which should be addressed first in
> that software or those installations, this DNSSEC bug or the
> recommendations in the mail message?  It it is a significant DNSSEC
> bug, it would be good if a future version of the mail message
>
> mentioned it.
>>
>
> It is not always a bug imho. Some resolvers, e.g., unbound, explicitly
> allow such permissive modes of DNSSEC validation, others support this
> implicitly and the rest may simply be not configured properly.
> Permissive modes are typically used during the incremental deployment
> phases prior to full adoption, e.g., to see that DNSSEC works ok, and does
> not break anything.
> Permissive mode introduces a security vulnerability - since a resolver
> signals support of DNSSEC, it receives large (often fragmented) responses,
> and thus may be vulnerable to our cache poisoning attack. On the other
> hand, network operators, may be concerned (often justly) with enforcing
> strict DNSSEC validation, due to interoperability (or other) problems (we
> discuss this in more detail in `Availability and Security Challenges
> Towards Adoption of DNSSEC`).
>
>>
>>
>>
>
> On Sat, Oct 19, 2013 at 7:14 PM, Haya Shulman <haya.shulman at gmail.com>wrote:
>
>> IMHO, DNSSEC is simply the natural defense against the attacks, which is why I did not explicitly mention it, but I definitely had it in mind :-)
>>
>> Regarding the proxy-behind-upstream: to prevent the attacks DNSSEC has to be deployed(and validated) on the proxy. Currently it seems that there are proxies that signal support of DNSSEC (via the DO bit), but do not validate responses, and validation is typically performed by the upstream forwarder.
>>
>> ---
>>
>> The complete absense of any mention of DNSSEC among those recommendations
>>
>>
>>
>>
>>
>>
>> (or elsewhere) reads like an implicit claim that DNSSEC would not
>> help.  Even if that claim was not intended, would it be accurate?
>>
>> Would DNSSEC make any of recommendations less necessary or perhaps
>> even moot?  If DNSSEC by itself would be effective against cache
>> poisoning, then isn't it among the recommendations, especially for
>> "Resolver-behind-Upstream"?  Why aren't efforts to protect port
>> randomization, hide hidden servers and so forth like trying to make
>> it safe to use .rhosts and /etc/hosts.equiv files by filtering ICMP
>> dedirects and IP source routing, and strengthening TCP initial sequence
>>>
>>> numbers?
>>
>>
>>
>> On Sat, Oct 19, 2013 at 6:53 PM, Haya Shulman <haya.shulman at gmail.com>wrote:
>>
>>> This is correct, 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.
>>>
>>>
>>> On Sat, Oct 19, 2013 at 6:05 PM, Phil Regnauld <regnauld at nsrc.org>wrote:
>>>
>>>> P Vixie (paul) writes:
>>>> > M. Shulman, your summary does not list dnssec as a solution to any of
>>>> these vulnerabilities, can you explain why not? Vixie
>>>>
>>>>         I was wondering about that, and went to look at the abstracts:
>>>>
>>>> http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16
>>>>
>>>> "Security of Patched DNS"
>>>>
>>>> [...]
>>>>
>>>> We present countermeasures preventing our attacks; however, we believe
>>>> that our attacks provide additional motivation for adoption of DNSSEC
>>>> (or other MitM-secure defenses).
>>>>
>>>>         So at least this seems to be mentioned in the papers themselves
>>>> (Id
>>>>         didn't pay to find out).
>>>>
>>>>         But I agree that the summary would benefit from stating this,
>>>> as it's
>>>>         currently only way to to avoid poisoning. Not stating it could
>>>> lead
>>>>         some to believe that these attacks are immune to DNSSEC
>>>> protection of
>>>>         the cache.
>>>>
>>>>         Cheers,
>>>>         Phil
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> 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
>>
>
>
>
> --
>
> 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/4a52f8f5/attachment.html>