<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div>On Thu, Sep 05, 2013 at 02:54:18PM -0700,<br> Paul Vixie <<a href="mailto:paul@redbarn.org">paul@redbarn.org</a>> wrote the part "i do not understand this statement.":</div></blockquote><blockquote type="cite"><div><br><blockquote type="cite">Florian Weimer wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Because DNSSEC does not prevent cache poisoning, it only detects it.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">i do not understand this statement.<br></blockquote><br></div></blockquote><div><br></div><div>On Sep 6, 2013, at 3:49, Stephane Bortzmeyer wrote in response to that exchange:</div><div><br></div><blockquote type="cite"><div>The way I understand it: with Kaminsky and/or Shulman, you can still<br>poison a DNS cache. The downstream validating resolver will detect it<br>and send back SERVFAIL to the end user. But this end user won't be<br>able to connect to his/her bank.<br></div></blockquote><div><br></div>You don't need Kaminsky- or Shulman-described attacks to 'poison' a cache, you just need to create an acceptable response message. There are other ways to do that.<br><br><blockquote type="cite"><div>So, DNSSEC turned the poisoning attack from a hijacking attack to a<br>DoS.<br></div></blockquote><div><br></div><div>The above has a few non-sequiters. First, yes, the cache poisoning is prevented, after it is detected. What you are complaining though is that this means the end user is blocked from reaching the desired service - as a result of the poisoning being thwarted.</div><div><br></div><div>The comparison you should be making is not between "user gets to service versus user is blocked by DNSSEC from accessing service" but rather "user is misdirected to malicious harbor versus user is blocked from accessing the malicious server." Yes, the latter is lose-lose because we are assuming this choice is being made during the duress of an attack.</div><div><br></div><div>It's not DNSSEC's fault that the user can't get through, it' the attack's fault. DNSSEC's job is first to protect the cache from having falsified data, not to protect the user. The result is to keep users from the bad sites they would have accessed if the cache were poisoned.</div><div><br></div><div>Note - DNSSEC does not address 'correctness' - which is at the heart of many problems today. If the provisioning interface security is subverted, incorrect data can get into the DNS, be armored by DNSSEC and result in caches holding incorrect data. DNSSEC's role is only to make this event more transparent - that the fault lay "upstream" - DNSSEC is not in any way going to defend against this class of failure.</div><br><blockquote type="cite"><div>Now, the question is: "for an attacker, is it the simplest way to do a<br>DoS?" IMHO, no, so I'm not too worried about it and I still believe in<br>DNSSEC.<br></div></blockquote></div><div><br></div>DoS and DDoS are not the only forms of attack seen in the wild. (D)Dos is usually not the goal but the means to an end, such as a political statement.<div><br></div><div>What has gone wrong in our plan to save the Internet(TM) is that DNSSEC's armor against cache poisoning has being used as malicious payload in DDoS attacks via reflections. But because the 'baddies" are after more than DDoS, we can't just drop DNSSEC and be better off. (Cur reference to talks at CENTR, DNS-OARC ... yadda, yadda, yadda...for further elaboration.)<div><br></div><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span></span>-=-=-=-<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Edward Lewis <span></span> <br>NeuStar <span></span> You can leave a voice message at +1-571-434-5468<br><br>There are no answers - just tradeoffs, decisions, and responses.</div></div></div></span></span>
</div>
<br></div></body></html>