<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"><div class="gmail_default"
style="font-family:tahoma,sans-serif">You are absolutely right, thanks
for pointing this out. <br>
</div></div>
</blockquote>
<br>
thanks for your kind words, but, we are still not communicating reliably
here. see below.<br>
<br>
<blockquote type="cite">
<div dir="ltr"><div class="gmail_default"
style="font-family:tahoma,sans-serif">DNSSEC is the best solution to
these (and other) vulnerabilities and efforts should be focused on its
(correct) adoption (see challenges here: <a
href="http://eprint.iacr.org/2013/254" style="font-family:arial"
target="_blank">http://eprint.iacr.org/2013/254</a>).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">However,
since partial DNSSEC deployment may introduce new vulnerabilities,
e.g., fragmentation-based attacks, the recommendations, that I wrote in
an earlier email, can be adopted in the short term to prevent attacks
till DNSSEC is fully deployed.</div></div>
</blockquote>
<br>
by this, do you mean that you have found a fragmentation based attack
that works against DNSSEC?<br>
<br>
by this, do you mean that if DNSSEC is widely deployed, your other
recommendations are unnecessary?<br>
<br>
in your next message you wrote:<br>
<br>
<span>Haya Shulman wrote:
<blockquote type="cite">
<div dir="ltr"><div class="gmail_default"
style="font-family:tahoma,sans-serif">..., the conclusion from our
results (and mentioned in all our
papers on DNS security) is to deploy DNSSEC (fully and correctly). We
are proponents of cryptographic defenses, and I think that DNSSEC is the
most suitable (proposed and standardised) mechanism to protect DNS
against cache poisoning. Deployment of new Internet mechanisms is always
challenging (and the same applies to DNSSEC). Therefore, we recommend
short term countermeasures (against vulnerabilities that we found) and
also investigate mechanisms to facilitate deployment of DNSSEC.<br>
</div></div></blockquote></span><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 class="moz-txt-link-freetext" href="http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/">http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/</a><br>
<br>
vixie<br>
</body></html>