<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">Haya Shulman wrote:
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">On Sat, Oct 19, 2013 at 9:21 PM, Paul Vixie <span
dir="ltr"><<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>></span>
wrote:<br>
<div class="gmail_quote"><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
bgcolor="#FFFFFF" text="#000000">by this, do you mean that you have
found a fragmentation based attack
that works against DNSSEC?<br>
<br></div></blockquote>[...]</div></div></div>
</blockquote>
<br>
i interpreted your answer to my question as "no", since every
counter-example you cited was a case where dnssec was used improperly.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><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
bgcolor="#FFFFFF" text="#000000">
by this, do you mean that if DNSSEC is widely deployed, your other
recommendations are unnecessary?<br></div></blockquote><div><br></div>[...]</div>
</div>
</div>
</blockquote>
<br>
i interpreted your answer to my question as "no", since every
counter-example you cited was a case where dnssec was used improperly.
most importantly, the lack of signed delegations and signed glue is by
design, and is not a weakness in dnssec, since the only remaining
vulnerability is denial of service, of which there are many other (and
easier) methods.<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"><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 bgcolor="#FFFFFF" text="#000000">
<br>in 2008, we undertook the short term (five years now) countermeasure
of
source port randomization, in order to give us time to deploy DNSSEC. if
five years made no difference, and if more short term countermeasures
are required, then will another five years be enough? perhaps ten years?
exactly how long is a "short term" expected to be?<br>
<br>
for more information, see:<br>
<br>
<a
href="http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/"
target="_blank">http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/</a></div></blockquote>
<div><br></div><div class="gmail_default"
style="font-family:tahoma,sans-serif">Thanks, you summarised this very
nicely. I'd like to bring it to your attention that, in contrast to
other sections, you did not cite our work explicitly, in a section where
you describe our fragmentation based attacks (please add it).</div></div>
</div>
</div>
</blockquote>
<br>
i'd have to read your published work before i could cite it. can you
tell me where to find it online, outside any paywall or other
restrictions? note that i'll be happy to respond, with citations, since
your work is so topical.<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">... I
believe that five years is not a significant time frame in terms of the
future of the Internet. So, IMHO it may be the case that further
countermeasures may be required.</div></div>
</div>
</div>
</blockquote>
<br>
i believe that if we can't make a significant difference in the
resiliency and quality of core internet infrastructure after 16 years,
then we wasted our time. and i know that if five more years wasn't
enough, then fifty years would also not be enough. as an industry we
must at some point either declare victory and stop creating lower
quality counter-measures which add complexity, or we must declare
failure and stop expecting dnssec to help with any problems we might
discover in the existing system.<br>
<br>
we can't realistically or credibly have it both ways.<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">BTW,
port randomisation prevents a number of attacks (not only cache
poisoning) and so is useful even when DNSSEC is fully deployed and
validated.<br>
</div></div>
</div>
</div>
</blockquote>
<br>
i'd like to hear more about this. at the moment i have no picture in my
head of "not only cache poisoning" when i think of the prevention
offered by source port randomization.<br>
<br>
vixie<br>
</body></html>