<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 22, 2013 at 6:20 PM, Paul Vixie <span dir="ltr"><<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>></span> wrote:<br>

<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 text="#000000" bgcolor="#FFFFFF">note, i am using <<span><a href="http://arxiv.org/pdf/1205.4011.pdf" target="_blank">http://arxiv.org/pdf/1205.4011.pdf</a>>
 as my reference to haya shulman's fragmentation related attack. i found
 this by googling for "fragmentation considered poisonous" which is the 
string i used to reference haya's work in my circleid blog post.<br>
  <br></span></div></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif">In the first message in this thread I referred to my site, where all updated papers are available.†</div><div class="gmail_default">

<font face="tahoma, sans-serif"><a href="http://sites.google.com/site/hayashulman/publications">sites.google.com/site/hayashulman/publications</a></font><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 text="#000000" bgcolor="#FFFFFF"><span>
</span><div class="im">Haya Shulman wrote:
<blockquote type="cite">
  <div dir="ltr"><div style="font-family:tahoma,sans-serif"><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></div>
</blockquote>
<br></div>
so if i add "first weaponized by Haya Shulman" this would settle the 
matter?<br></div></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thank you, can you please use Amir Herzberg and Haya Shulman (I collaborated on this attack together with my phd advisor Amir Herzberg).</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 text="#000000" bgcolor="#FFFFFF">
<br>
as to bernstein, i credit him with source port randomization but not 
with spoofed-source guessing attack which was first told to me by peter 
shipley in 1994 when BIND's TXID generator was a simple increment. i 
added simplistic randomization, against which theo de raadt weaponized a
 TXID predictor. the randomized TXID generator in later BIND 4 and all 
of BIND 8 was theo de raadt's work. kaminsky's innovation was not to 
weaponize it, we all knew that a sustained flow at 100Mbit/sec would 
yield a correct guess in a matter of ten minutes or so. kaminsky's 
innovation was to include poison NS RR's which would overwrite the cache
 (coming as they appeared to come, from the apex of the zone, which is 
considered more credible than the delegation from the ancestor). 
bernstein's source port randomization was argued at the time only by 
cache poisoning of single records, and on that basis, the cost/benefit 
was wrong -- as witness the problems caused by source port randomization
 for stateful firewalls and NATs. only kaminsky's NS RR poisoning raised
 the cost of cache poisoning to the point where source port 
randomization was economically justified.
</div></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Ok, thank you for the clarification.</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 text="#000000" bgcolor="#FFFFFF"><blockquote type="cite">
  <div dir="ltr">
    <div style="font-family:tahoma,sans-serif"><div class="im"><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><div>I do not advocate to deploy these or other countermeasures. ...</div></div>
  </div>
</blockquote>
<br>
yes, you are, and you have been. when you worked before publication to 
pre-notify implementors and operators about your problem, it was on the 
basis of your stated expectation that this was a big problem and would 
require an immediate fix. you've been challenged on that assertion. 
given a finite "fix the dns's security problems" global aggregate 
budget, your fragmentation attack is nowhere near the top of the 
priority list. so while your observations are accurate, there's a lot 
more operational security to be had by fixing other things which will be
 easier. for example, source port randomization is nowhere near 
universal, and nonrandomizing caching resolvers are a greater danger to 
us all than your fragmentation related attack. furthermore the outdated 
CPE's which de-randomize source ports are a bigger problem than your 
fragmentation related attack, and they MUST be fixed before your 
fragmentation related attack will be tractable. and of course, DNSSEC is
 not universally deployed, which poses a far greater risk to us all than
 your fragmentation related attack, since any on-path attacker has 
complete control of the dns cache today.<br></div></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I appreciate your comments on this issue. The reason for this was that we were concerned with the legal implications of a disclosure of such attacks, and we did not want to publish them before coordinating careful disclosure. We wanted to make sure all relevant parties were notified. After discussing this with the EFF, we understood that since we tried to disclose and notify the impacted parties, we were `ok`, and so we sent the work for publication at a security conference (which was accepted and will appear soon).</div>

<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I agree with you that there are other vulnerabilities, which may be easier for attackers to exploit, that have to be addressed.†</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 text="#000000" bgcolor="#FFFFFF">
<br>
i challenged you privately, and i now do so publicly, to state why your 
fragmentation related attack was a greater menace to the internet than 
other known problems in DNS such as: lack of universal SPR, 
derandomizing NAT boxes, or lack of DNSSEC. your weaponization in 2012 
of the fragmentation related attack first told to me in 2008 by florian 
weimer did not warrant a CERT advisory, nor private circulation of the 
vulnerabillity, because far from needing to be fixed urgently, it is 
unlikely to ever be fixed at all, because as stated, there are bigger 
problems which deserve priority attention, which in their aggregate will
 obviate your attack through indirect means.<div class="im"><br>
<br>
<blockquote type="cite">
  <div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra"><div style="font-family:tahoma,sans-serif">Which brings me to the topic of 
resolver-behind-upstream attacks which were not commented upon.</div>



<div 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 style="font-family:tahoma,sans-serif">This 
configuration is still believed to be secure and is recommended by 
experts.</div></div></div>
</blockquote>
<br></div>
well, if i'm an expert, then not all experts think that outsourcing 
recursive dns (to opendns, or to google, or to one's ISP) is secure or 
reasonable. i want the record to be clear on that point -- people should
 run their own recursive dns, on-prem or in-laptop. i'll make an 
exception for smart phones, who should be using their provider's 
recursive DNS, and not google's or opendns. your observations about 
fragmentation related vulnerabilities in the use of wide area recursive 
dns are welcome, since we need more nails for the coffin that wide area 
recursive dns belongs in. but it was already a bad idea even before your
 fragmentation related observations were published.</div></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I absolutely agree with you, deploying DNSSEC on the end hosts would be ideal for security.</div>

<div class="gmail_default" style="font-family:tahoma,sans-serif">There are obstacles to this though, that may have to be addressed in some networks, including support by applications, interoperability problems, and even other issues that may discourage clients from validating, e.g., as you published, ISPs mangling NXDOMAIN responses.†</div>

<div class="gmail_default" style="font-family:tahoma,sans-serif">I think I may have been misinterpreted. I believe cryptography is important and efforts should be invested in deployment of DNSSEC. One of the goals of our work on DNS was to motivate adoption of DNSSEC.</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 text="#000000" bgcolor="#FFFFFF"><span class=""><font color="#888888"><br>
<br>
vixie<br>
</font></span></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">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>