<html><head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">Haya Shulman wrote:
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"><br>
<div>
> > 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></div></div></div>
</blockquote>
<br>
upon deeper consideration, "weaponized" is the wrong verb, unless you
have released your software. i can say "first published" if that will
serve your purpose.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><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>
</div>
</div>
</blockquote>
<br>
i can't tell whether you're wrong, there's not enough detail here. if
you're able to replace the middle fragment, or perhaps replace all
fragments except the last one, then only SIG(0) or TSIG or DNSSEC could
stop you. however, my back of envelope estimate is that replacing the
middle fragment with one the same size but different content is more
than just "tricky", and replacing all-but-the-last fragment would
require many hours at 100MBit/sec, which to me places it out of
consideration as an attack worth defending against.<br>
<br>
i believe that mark andrews of ISC is going to re-release eastlake
cookies. i expect that in consideration of your fragmentation work, he
will add a 32-bit CRC covering the full message to the EDNS option that
contains the cookie. since the cookies method is something we need
anyway (for DDoS prevention), we ought to depend on it to solve for
fragmentation as well.<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><div><br></div><blockquote
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"><div>
<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.</div></div>
</div>
</div>
</blockquote>
<br>
that is, again, not what i said. i want recursion, iteration, and
caching to occur on-premise or if necessary on-host. i will want this
even in the absence of globally deployed dnssec. i will also want
on-premise or if necessary on-host validation where possible, but that's
not what i was saying in the text you quoted.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="gmail_default" style="font-family:tahoma,sans-serif">
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>
</div>
</div>
</div>
</blockquote>
<br>
that's a controversial topic, as i expect followups to this thread to
demonstrate. i won't address it here.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
</blockquote></div>
</div>
</div>
</blockquote>
<br>
a side by side reading of your earlier draft
(<a class="moz-txt-link-freetext" href="http://arxiv.org/pdf/1205.4011.pdf">http://arxiv.org/pdf/1205.4011.pdf</a>) and your current draft:<br>
<br>
<span><a
href="https://0a94266f-a-62cb3a1a-s-sites.googlegroups.com/site/hayashulman/files/fragmentation-poisoning.pdf?attachauth=ANoY7cpB1yJsBXMWL0_spxDjUMV9m5G_TjI98UgJE6OtoP98H-WrlRJ2AyJVhajdZ5za2vjZ14twuMHuB7NUcRW_EYv36scybuofLgPOwoU2Rvs7zpSnm_Qj3jA3noSc3ibX9b9_7tncZJdGca0FLY8SOrzMTY_O5bd0NPcwBXtDx9vtCjbRisMFf48MiOYFNO-66BY3iyGa584pJ0Sy2vYfI5ZKKCmvJhJsmY96N4XChK5cGgky8eg%3D&attredirects=0">https://0a94266f-a-62cb3a1a-s-sites.googlegroups.com/site/hayashulman/files/fragmentation-poisoning.pdf?attachauth=ANoY7cpB1yJsBXMWL0_spxDjUMV9m5G_TjI98UgJE6OtoP98H-WrlRJ2AyJVhajdZ5za2vjZ14twuMHuB7NUcRW_EYv36scybuofLgPOwoU2Rvs7zpSnm_Qj3jA3noSc3ibX9b9_7tncZJdGca0FLY8SOrzMTY_O5bd0NPcwBXtDx9vtCjbRisMFf48MiOYFNO-66BY3iyGa584pJ0Sy2vYfI5ZKKCmvJhJsmY96N4XChK5cGgky8eg%3D&attredirects=0</a>
<br>
<br>
...shows a remarkably different attitude toward dnssec. what led to your
reconsideration?<br>
<br>
vixie<br>
</span></body></html>