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

[Haya Shulman]

>
> My problem with your findings is that your are grossly overstating
> their significance. None of them will ever be seen in the wild. As
> As http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 and
> as I've said, showing the inevitiable weakness of port randomization
> is good.


We found and described the vulnerability and showed how to apply it against
standard and patched resolvers. Can you please clarify in what way our
results `grossly overstate` significance?
Your second argument is not precise, we, and recently others, showed these
attacks to be practical. Could you please explain why you are certain that
the attacks do not pose a practical risk?

I'm sorry, but I think the mention of DNSSEC in your paper exists only
> because others forced it. I'm forced to that belief by various things
> including your refusal admit the obvious about relative priorities and
> by statements like that sentence above that suggests that fixing port
> randomization could be easier than deploying DNSSEC in any except quite
> exceptional cases.


This conspiracy theory is intriguing...



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131021/6e376fd7/attachment.html>