<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><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">
I notice that besides not answering the priority question, you also<br>did not say where we can read your paper to see whether you mention<br>DNSSEC only as a coerced afterthought.</blockquote><div><br></div><div><span>@</span><i style="font-size:medium;font-family:'Times New Roman'">Vernon Schryver </i></div>
<div>Please read my first post in this thread, you should find all information there.</div>
<div> </div><div><br></div><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">Should the organizations responsible for BIND, nsd, and unbound to<br>
work on DNSSEC improvements and bug fixes before or after your<br>issues? Please do not feel constrained to give a single general<br>answer for all three organizations but please give 3 specific answers<br>for those 3 specific organizations.</blockquote>
<pre>@<i style="font-family:'Times New Roman';font-size:medium">Vernon Schryver</i></pre><pre><span style="font-family:tahoma,sans-serif;color:rgb(34,34,34)">Requiring such answers from me is absolutely out of place, I am probably not aware of the constraints that organisations face in their every day operation of the Internet, and so I never argued which coutermeasures must be deployed and by whom. My goal is to identify vulnerabilities and investigate and recommend countermeasures that can prevent them. Each organisation should decide what solution suites its needs best, based on this and other information that is available to it.</span></pre>
</div><div>It is also ironic that especially those that emphasise their own credit, experience, and reputation, and even use it to justify and back-up their arguments (i.e., `proof-by-intimidation` :-)), are so negligient to the work of others. Such a conduct can do more damage to the community than good. I hope that this is only a misunderstanding...</div>
<div><br></div><div>---</div>
<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"><span style="font-size:12.727272033691406px">thanks for clarifying that. i cannot credit your work in the section of<br>
</span><span style="font-size:12.727272033691406px">my article where i wrote about fragmentation, because you were not the<br></span><span style="font-size:12.727272033691406px">discoverer.</span></blockquote><div><br></div>
<div>@<i style="font-size:medium;font-family:'Times New Roman'">Paul Vixie</i> </div><div>BTW, when we shared this attack with you, after some correspondence where we explained the details, you wrote to us admiting that it was different from the vulnerability that Florian discussed with you (I can forward that email if you prefer). </div>
<div>But, irrespectively, even if it was suggested that fragmentation poses a vulnerability (and indeed it has a long history of attacks) - there is a difference between suggesting something and actually doing it (there are different pieces that need to be put together). Had there been a source where this attack was described, I would have of course cited it, this is the only ethical thing to do.</div>
<div>As I wrote in an earlier email, port randomisation vulnerability was identified long ago by Bernstein, and yet Paul Vixie (justly) credits Dan Kaminsky for putting the pieces together. Of course Dan deserves the credit - putting it all together requires research and work. So, I look forward to seeing this fixed.</div>
<div><br></div><div>---</div><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"><br>On what do you base your claims about the fatal costs of DNSSEC<br>
validation?</blockquote><div><br></div><div>@<i style="font-size:medium;font-family:'Times New Roman'">Vernon Schryver</i></div><div>There are significant research efforts targeted at identifying deployment problems and providing recommendations, e.g., see recent work published at USENIX'13:</div>
<div><a href="http://cseweb.ucsd.edu/~hovav/papers/lrss13.html" target="_blank">http://cseweb.ucsd.edu/~hovav/papers/lrss13.html</a><br></div><div><br></div><div>This work performed a study of DNSSEC deployment and also quantified failures that validating resolvers experience. You may find it relevant.</div>
<div>Trying to ignore or deprecate such research, and discussions thereof, and employing `proof-by-intimidation` arguments, will not benefit this community.</div><div><br></div><div><br></div><div>---</div><div><br></div>
<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">
I for one, do not believe DNSSEC is any difficult. I have turned DNSSEC<br> wherever I can. It has become easier and easier in the past few years to<br> the point I would call deploying DNSSEC today trivial.</blockquote>
<pre><br></pre></div><div><i style="font-size:medium;font-family:'Times New Roman'">@Daniel Kalchev</i></div><div>Of course there are networks that may not have problems, this is not the _question_, the challenge is related to those that cannot for some reason, or are not motivated to do so. It is great that there are experts such as yourself that can quickly and easily adopt DNSSEC. But as you know Internet is composed of different networks, and there are organisations and networks of different size and with different dependencies and constraints, so, I am afraid that the fact that you found it easy to deploy DNSSEC and do not experience problems with it, does not constitute a general proof :-)</div>
<div><br></div><div><br></div><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">Disclosing such potential vulnerabilities remains valuable work, but I<br>
think careful consideration needs to be applied to the engineering<br>economics of the best operational-world mitigation approaches.</blockquote></div><div><br></div><div>---</div><div><br></div><div>@<i style="font-size:medium;font-family:'Times New Roman'">Keith Mitchell</i></div>
<div>I do not advocate to deploy these or other countermeasures. Above any doubt you are in the best position to decide which countermeasures to deploy. I am probably not aware of some of the constraints that organisations face in their every day operation of the Internet, and so I never argued who should deploy what. We identify problems and provide recommendations explaning why they may prevent the problems. </div>
<div>The situation with DNS checkers is different from deployment of port randomisation. DNS checkers is a very important service to the community and the efforts that their operators took to make them available is very valuable. </div>
<div>However, an illusion of security is more dangerous than not being protected at all (in the later case one is aware that he is not protected and may be attacked). Clients rely on such reports for their security.</div>
<div>I admit that I do not know what economic effort is required to patch DNS checkers which report per-destination ports, recommended in [RFC6056], as secure, but I suggested a fix to this vulnerability some time ago, that should be fairly simple to implement; the problem with the porttest checker is that each IP address of the checker system receives a single query from the tested resolver, and so to each such IP address a random port is selected. But, if more than a single query were sent to each checker IP during the test, then the predictable sequence would be easily identified.</div>
<div><br></div><div>---</div><div><br></div><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">Port randomization is an extremely thin reed for security, because<br>
there are so few port number bits.</blockquote></div><div><br></div><div>@<i style="font-size:medium;font-family:'Times New Roman'">Vernon Schryver </i></div><div>There are techniques to artificially inflate ports' distribution, and we already described one technique in ESORICS'12 paper.</div>
<div><br></div><div>---</div><div><br></div><div>I am glad to see that there is interest in our work, and that it triggers such elaborate discussion. </div><div>The stressed responses by some make me wonder if it may be the case that some would prefer that these attacks stayed hidden from the public eye - and since I am generally against security by obscurity and proofs by intimidation, this actually encouranges me to continue the research on DNS security, and in particular to study the practicality of the vulnerabilities :-)</div>
</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:tahoma,sans-serif">Which brings me to the topic of resolver-behind-upstream attacks which were not commented upon.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">As you know, one of the recommendations of experts and Internet operators, following Kaminsky attack, was `either deploy patches or configure your resolver to use a secure upstream forwarder`, e.g., OpenDNS was typically recommended. The security is established since the resolver is hidden from the Internet and sends its requests only via its upstream forwarder.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">This configuration is still believed to be secure and is recommended by experts.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">As you know we found vulnerabilities in such configuration, and designed techniques allowing to find the IP address of the hidden resolver, and then to discover its port allocation (the attacks apply to per-destination ports recommended in [RFC6056] or to fixed ports).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">This attack can be extremely stealthy and efficient, and applies to networks where communication between the resolver and upstream forwarder is not over TCP, and therefore can be fragmented (fragmentation of a single byte suffices).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"> We also confirmed with measurements that this vulnerability applies to a large fraction of neworks that use upstream forwarder. Some may claim these networks are probably not security aware in the first place and are anyhow vulnerable to other attacks.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">However, this is not so, among the vulnerable networks there are `security aware` networks, that use this configuration and offload recursive resolver services to dedicated third parties, since it is recommended by the experts and is believed to be secure. In particular, the upstream forwarder is often even validating DNSSEC, and is operated by a dedicated organisation, that provides proprietary services of secure upstream forwarding only to a limited number of networks.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">The problem is that operators of these networks believe to have deployed all the required countermeasures and protected themselves from attacks, while they may be vulnerable to attacks. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">Please see paper for more details and a brieft abstract in the first message on this thread.</div><br><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"></font></span></p><div class="gmail_default" style="font-family:tahoma,sans-serif;display:inline">
<font color="#000000"></font></div><span style="font-size:11pt;font-family:Calibri,sans-serif">Haya Shulman</span><p></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">Mornewegstr. 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>