<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Sorry for delay, I was omw to a different continent. </div><div class="gmail_default" style="font-family:tahoma,sans-serif">Please see response below.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">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><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"><div class="im">Haya Shulman wrote:
<blockquote type="cite">
<div dir="ltr"><div style="font-family:tahoma,sans-serif">You are absolutely right, thanks
for pointing this out. <br>
</div></div>
</blockquote>
<br></div>
thanks for your kind words, but, we are still not communicating reliably
here. see below.<div class="im"><br>
<br>
<blockquote type="cite">
<div dir="ltr"><div 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 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></div>
by this, do you mean that you have found a fragmentation based attack
that works against DNSSEC?<br>
<br></div></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif">One of the factors, causing fragmentation, is signed responses (from zones that adopted DNSSEC). Signed responses can be abused for DNS cache poisoning in the following scenarios: (1) when resolvers cannot establish a chain-of-trust to the target zone (very common), or (2) when resolvers do not perform `strict validation` of DNSSEC. As we point out in our work, many resolvers currently support such mode (some implicitly, others explicitly, e.g., Unbound), i.e., signal support of DNSSEC, however accept and cache spoofed responses (or, e.g., responses with missing or expired keys/signatures).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif">According to different studies, it is commonly accepted that only about 3% of the resolvers perform validation. One of the reasons for support of permissive DNSSEC validation is interoperability problems, i.e., clients/networks may be rendered without DNS functionality (i.e., no Internet connectivity for applications) if resolvers insist on strict DNSSEC validation, and e.g., discard responses that are not properly signed (i.e., missing signatures). </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Our attacks apply to such resolvers. Furthermore, many zones are misconfigured, e.g., the parent zone may serve an NSEC (or NSEC3) in its referal responses, while the child is signed (e.g., this was the case with MIL TLD).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"></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">
by this, do you mean that if DNSSEC is widely deployed, your other
recommendations are unnecessary?<br></div></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Some of our recommendations are still relevant even if DNSSEC is widely deployed. We showed attacks that apply to properly signed zones and strictly validating resolvers. Since referral responses are not signed, the attacker can inject spoofed records (e.g., A records in glue) which will be accepted by the resolvers. Such cache poisoning can be used for denial (or degradation) of service attacks - a strictly validating resolver will not accept unsigned responses from the attacker and will be stuck with the malicious cached name server records (unless the resolver goes back to the parent zone again - however such behaviour is not a security measure and should not be relied upon).</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Furthermore, in the proxy-behind-upstream setting, even when DNSSEC is supported by all zones and is validated by the upstream forwarder, but not by the proxy, the proxy can be attacked. Ideally validation should be at the end hosts - we are not there yet with DNSSEC.<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 bgcolor="#FFFFFF" text="#000000">
<br>
in your next message you wrote:<br>
<br>
<span>Haya Shulman wrote:
<blockquote type="cite">
<div dir="ltr"><div 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 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 class="gmail_default" style="font-family:tahoma,sans-serif">My response to your question is the following: DNSSEC is a new mechanism, crucial for long term (future) security of the Internet. The concern that you are raising applies to other new mechanisms as well, e.g., BGP security and even IPv6, and is not specific to DNSSEC. Deploying new mechanisms in the Internet has always been a challenge, and the mechanisms may go through a number of adaptations during the incremental deployment phases, and intermediate transition mechanisms may be designed. 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 class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><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.</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"><span class=""><font color="#888888"><br>
<br>
vixie<br>
</font></span></div>
</blockquote></div><br><br><div class="gmail_default" style="font-family:tahoma,sans-serif">Best Regards,</div><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">Morewegstr. 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>