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

Haya Shulman haya.shulman at gmail.com
Sat Oct 19 15:53:00 UTC 2013


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


More information about the dns-operations mailing list