<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline">




</div><span>In that case, on what should an organization spend time or money</span></blockquote><pre>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 </pre><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">




<div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline"><span style="font-family:arial">    data not yet protected with DNSSEC.</span></div></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">




<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div>




<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">




<div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline"></div><span>That sounds like a more significant bug than port obscurity or</span></blockquote><pre>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 </pre><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">




<div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline"><span style="font-family:arial">mentioned it.</span></div></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">




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. </div><div class="gmail_default" style="font-family:tahoma,sans-serif">




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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">


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`). </div>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline"></div><br></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">




<div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline"></div><br></blockquote><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Oct 19, 2013 at 7:14 PM, Haya Shulman <span dir="ltr"><<a href="mailto:haya.shulman@gmail.com" target="_blank">haya.shulman@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><pre><pre>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 :-)</pre>



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




<pre>---</pre></pre><pre><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The complete absense of any mention of DNSSEC among those recommendations</blockquote>




(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
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">numbers?</blockquote></pre></div><div><div><div class="gmail_extra">




<br><br><div class="gmail_quote">On Sat, Oct 19, 2013 at 6:53 PM, Haya Shulman <span dir="ltr"><<a href="mailto:haya.shulman@gmail.com" target="_blank">haya.shulman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div>







<div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Sat, Oct 19, 2013 at 6:05 PM, Phil Regnauld <span dir="ltr"><<a href="mailto:regnauld@nsrc.org" target="_blank">regnauld@nsrc.org</a>></span> wrote:<br>





<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>P Vixie (paul) writes:<br>
> M. Shulman, your summary does not list dnssec as a solution to any of these vulnerabilities, can you explain why not? Vixie<br>
<br>
</div>        I was wondering about that, and went to look at the abstracts:<br>
<br>
<a href="http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16" target="_blank">http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16</a><br>
<br>
"Security of Patched DNS"<br>
<br>
[...]<br>
<br>
We present countermeasures preventing our attacks; however, we believe<br>
that our attacks provide additional motivation for adoption of DNSSEC<br>
(or other MitM-secure defenses).<br>
<br>
        So at least this seems to be mentioned in the papers themselves (Id<br>
        didn't pay to find out).<br>
<br>
        But I agree that the summary would benefit from stating this, as it's<br>
        currently only way to to avoid poisoning. Not stating it could lead<br>
        some to believe that these attacks are immune to DNSSEC protection of<br>
        the cache.<br>
<br>
        Cheers,<br>
        Phil<br>
</blockquote></div><br><br clear="all"><div><br></div></div></div>-- <br><div><div dir="ltr"><div><p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Haya Shulman</font></span></p>







<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Technische Universität Darmstadt<u></u><u></u></font></span></p>







<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">FB Informatik/EC SPRIDE<u></u><u></u></font></span></p>







<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Morewegstr. 30<u></u><u></u></font></span></p>







<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">64293 Darmstadt<u></u><u></u></font></span></p>







<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Tel. <a value="+4961511675540">+49 6151 16-75540</a><u></u><u></u></font></span></p>







<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><a href="http://www.ec-spride.de/" target="_blank"><font color="#000000">www.ec-spride.de</font></a></span></p>







</div></div>
</div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Haya Shulman</font></span></p>




<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Technische Universität Darmstadt<u></u><u></u></font></span></p>




<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">FB Informatik/EC SPRIDE<u></u><u></u></font></span></p>




<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Morewegstr. 30<u></u><u></u></font></span></p>




<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">64293 Darmstadt<u></u><u></u></font></span></p>




<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Tel. <a value="+4961511675540">+49 6151 16-75540</a><u></u><u></u></font></span></p>




<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><a href="http://www.ec-spride.de/" target="_blank"><font color="#000000">www.ec-spride.de</font></a></span></p>




</div></div>
</div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Haya Shulman</font></span></p>


<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Technische Universität Darmstadt<u></u><u></u></font></span></p>


<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">FB Informatik/EC SPRIDE<u></u><u></u></font></span></p>


<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Morewegstr. 30<u></u><u></u></font></span></p>


<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">64293 Darmstadt<u></u><u></u></font></span></p>


<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><font color="#000000">Tel. <a value="+4961511675540">+49 6151 16-75540</a><u></u><u></u></font></span></p>


<p style="margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif"><a href="http://www.ec-spride.de/" target="_blank"><font color="#000000">www.ec-spride.de</font></a></span></p>


</div></div>
</div></div>