> > 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.shul...@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.shul...@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 <regna...@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
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
