<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 Mon, Oct 21, 2013 at 1:42 PM, P Vixie <span dir="ltr"><<a href="mailto:vixie@fsi.io" target="_blank">vixie@fsi.io</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Tuesday, October 22, 2013 19:47:34 Haya Shulman wrote:<br>
> On Tue, Oct 22, 2013 at 6:20 PM, Paul Vixie <<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>> wrote:<br>
> > note, i am using <<a href="http://arxiv.org/pdf/1205.4011.pdf" target="_blank">http://arxiv.org/pdf/1205.4011.pdf</a>> as my reference to<br>
> > haya shulman's fragmentation related attack. i found this by googling for<br>
> > "fragmentation considered poisonous" which is the string i used to<br>
> > reference haya's work in my circleid blog post.<br>
><br>
</div><div>> updated papers are available.<br>
> <a href="http://sites.google.com/site/hayashulman/publications" target="_blank">sites.google.com/site/hayashulman/publications</a><br>
<br>
</div>so noted.<br>
<div><br>
> > so if i add "first weaponized by Haya Shulman" this would settle the<br>
> > matter?<br>
><br>
> Thank you, can you please use Amir Herzberg and Haya Shulman (I<br>
> collaborated on this attack together with my phd advisor Amir Herzberg).<br>
<br>
</div>it shall be done.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thank you.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> I agree with you that there are other vulnerabilities, which may be easier<br>
> for attackers to exploit, that have to be addressed.<br>
<br>
</div>do you also agree with me that they would have to be addressed first, since<br>
they represent greater risks, and do you also agree that if the other known<br>
problems are addressed (for example, using eastlake cookies) that your<br>
fragmentation related vulnerabilities will have been resolved by side-effect?<br>
<br></blockquote><div><div class="gmail_default" style="font-family:tahoma,sans-serif">I agree with you that plenty other concerns have to be addressed. I also agree that full and correct DNSSEC deployment would prevent the attacks. </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Eastlake cookies is a very neat proposal. In contrast to other challenge-response mechanisms, which reuse existing fields for security (while those fields were originally designed for a different purpose), e.g., source ports, Eastlake's proposal uses the EDNS to add randomness in order to authenticate communication between resolver and name server. So, you are right, it does prevent many attacks, but, it does not prevent all the attacks, particularly those that exploit fragmentation. For instance:</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">1. what about an IP packet that is fragmented into three fragments, such that the EDNS OPT RR is in the third fragment? By replacing the second fragment, the attacker can inject malicious content.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">2. another example also involves IP fragmentation, however in this scenario the second fragment can be of any size, e.g., a single byte. The attacker overwrites the transport layer port of the first fragment, e.g., to its own port and intercepts the packet (along with the cookie); replaces the DNS records and forwards the resulting response to the resolver.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Both tricky but feasible. </div><div class="gmail_default" style="font-family:tahoma,sans-serif">
Correct me if I am wrong, but I think that the cookies would not prevent these (above) attacks. </div></div><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> > ... not all experts think that outsourcing<br>
<div>> > recursive dns (to opendns, or to google, or to one's ISP) is secure or<br>
> > reasonable. i want the record to be clear on that point -- people should<br>
> > run their own recursive dns, on-prem or in-laptop. i'll make an exception<br>
> > for smart phones, who should be using their provider's recursive DNS, and<br>
> > not google's or opendns. your observations about fragmentation related<br>
> > vulnerabilities in the use of wide area recursive dns are welcome, since<br>
> > we need more nails for the coffin that wide area recursive dns belongs in.<br>
> > but it was already a bad idea even before your fragmentation related<br>
> > observations were published.<br>
><br>
> I absolutely agree with you, deploying DNSSEC on the end hosts would be<br>
> ideal for security.<br>
<br>
</div>wait, wait, that's not what i said. i said recursive dns should be on-premise<br>
or on-host, not wide-area. i said nothing about end to end dnssec. what are<br>
you specifically agreeing with?<br></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Yes you are right, I agree with you that it is best to validate on recursive resolver on-premise. But, I also wanted to add, that I think best to validate on the end host; this would also prevent attacks by attackers that are on the same network with the client, e.g., wireless networks or networks of ISPs.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> There are obstacles to this though, that may have to be addressed in some<br>
> networks, including support by applications, interoperability problems, and<br>
> even other issues that may discourage clients from validating, e.g., as you<br>
> published, ISPs mangling NXDOMAIN responses.<br>
<br>
</div>this is nonsequitur. it's as if i'd asserted A and you'd said "B is<br>
complicated".<br>
<div><br>
> I think I may have been misinterpreted. I believe cryptography is important<br>
> and efforts should be invested in deployment of DNSSEC. One of the goals of<br>
> our work on DNS was to motivate adoption of DNSSEC.<br>
<br>
</div>that's great to hear.<br>
<span><font color="#888888"><br>
vixie<br>
</font></span></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>