<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 style="color:rgb(0,0,0)">I do not see an answer to my intended question. Again, given inevitiably</span></blockquote><pre style="color:rgb(0,0,0)">limited real time, over-committed programmer and DNS adminstrator
hours, and limited money, should problems in DNSSEC implementations
and installations be addressed before or after your issues?</pre><pre style="color:rgb(0,0,0)"><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">
<br></blockquote><div> </div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">Some of our recommendations can be useful for security (also against other attacks - see earlier email), and can assist with interoperability problems, that may emerge during deployment of DNSSEC.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">For instance, our recommendations for IP layer, e.g., reducing IP defragmentation cache size or randomising IP-ID, can be useful not only against poisoning attacks (in particular, fragmentation has a long history of exploits for denial/degradation of service attacks); Port randomisation is also a useful feature, not only against cache poisonig (see earlier email); and so on.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"></div><br></div>Should the people working on DNS implementations prioritize making
their DNSSEC code more robust and easier to use above or below
addressing your issues?</pre><pre style="color:rgb(0,0,0)"><br></pre><pre style="color:rgb(0,0,0)"><div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline">I do not think that there is a general answer to this question, as it depends on the specific organisation/network. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline"></div><span style="font-family:tahoma,sans-serif"></span></pre><pre style="color:rgb(0,0,0)"><br></pre><pre style="color:rgb(0,0,0)">Which should be built or fixed first, mechanisms such as auto-signing
that make DNSSEC easier to deploy and more robust (e.g. reducing
accidental signature expiration), or your cache pollution issues?
Should requests for proposals and requests for quotes rank DNSSEC
features including ease of DNSSEC use above or below fixes for your
cache pollution issues?
Should you spend most of your own time looking for improvements and
bugs in DNSSEC or looking for more ways to pollute DNS caches where
DNSSEC is not used?</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">
</div></blockquote><div><div class="gmail_default" style="font-family:tahoma,sans-serif">Both are important: (1) disclosing attacks raises awareness to the significance of systematic defenses, and motivates deployment thereof; it also enables the networks to protect themselves in the meanwhile. I would not be surprised if similar attacks were deployed in the Internet, without anyone being aware of their existence. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">(2) I also study deployment challenges and improvements (and not only attacks).</div>
<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"> </blockquote><pre style="color:rgb(0,0,0)">I think that is neither a response to my claim, accurate, nor
relevant to what I understood of your claim about forwarders.
How can something that introduces a security vulnerability not always
be a bug in your or anyone's opinion?</pre><pre style="color:rgb(0,0,0)"><div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline">---</div><br></pre><pre style="color:rgb(0,0,0)"><div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline">
Sure, permissive mode is an explicit feature. I believe a bug is something that is not intentionally introduced.... (well, at least not as a general rule).</div>
<br></pre><pre style="color:rgb(0,0,0)"><div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline">---</div>
If you meant instead to say that permissive verification is a less
important bug that other things, then how do you rank your cache
pollution issues against other bugs starting with not deploying DNSSEC?</pre><pre style="color:rgb(0,0,0)"><br></pre><pre style="color:rgb(0,0,0)"><div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline">
---</div></pre><pre style="color:rgb(0,0,0)"><div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline">I would hope that disclosure may help some organisations and networks protect themselves. The other option is to be unaware of the vulnerabilities (and their exploits). </div>
<span style="font-family:tahoma,sans-serif">Do you think vulnerabilities are better left for attackers to take care of?<div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline"> </div></span><span style="font-family:tahoma,sans-serif">BTW, we withheld some of the works from publication, and tried to coordinate disclosure.</span></pre>
<pre style="color:rgb(0,0,0)">
Your work would be valuable if it helped pressure people to get
busy on DNSSEC. However, instead of saying "Use DNSSEC because
port randomization has these newly discovered weaknesses", you only
<div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline"></div>grudgingly and under pressure admit that DNSSEC even exists.<span style="font-family:tahoma,sans-serif;color:rgb(34,34,34)"></span></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"></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif">
Many networks cannot deploy DNSSEC overnight, due to different factors. Port randomisation algorithms that were proposed have weaknesses, but proper randomisation should solve these problems. </div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I was under pressure to catch a flight when I responded and forgot DNSSEC; it is as dear to me as it is to you :-)</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Oct 20, 2013 at 10:42 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"><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>
<div><div class="h5">
<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></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>