<div dir="ltr"><div class="gmail_default" style="font-family:garamond,serif">I hope you do not mind me joining in.</div><div class="gmail_default" style="font-family:garamond,serif"><br></div><div class="gmail_default" style="font-family:garamond,serif">

FYI, (a short) updated version of the paper is enclosed. </div><div class="gmail_default" style="font-family:garamond,serif"><br></div><div class="gmail_default" style="font-family:garamond,serif">I do not plan to release a PoC, but I will be happy to discuss questions and challenges pertaining to the implementation/evaluation. The results reported in the paper are based on evaluation of attacks against responses from real name servers, and (up-to-date) Bind and Unbound resolvers that I ran in a lab.</div>

<div class="gmail_default" style="font-family:garamond,serif"> We work on `some measurements` that should clarify the severity and applicability of the attack. However, the main problem is lack of time, and all these travels in tandem with hotels' networks do not speed it up. So unfortunately, it is taking me longer than we were hoping for.</div>

<div class="gmail_default" style="font-family:garamond,serif"><br></div><div class="gmail_default" style="font-family:garamond,serif">Please notice that I am not urging anyone to patch :-) and I do not promote any company, and do not have the required time to visit vendors around the globe and demonstrate the attack.<br>

</div><div class="gmail_default" style="font-family:garamond,serif">We disclosed the work to raise awareness to the vulnerability, and the paper is available. I think you _should_ patch and not wait till the exploit is out there. </div>

<div class="gmail_default" style="font-family:garamond,serif"><br></div><div class="gmail_default" style="font-family:garamond,serif">IMHO DNSSEC is a long term solution and I think that more research is required to address different obstacles towards adoption thereof, such as problems with large UDP packets, fragmentation, failures due to fall back to TCP, lack of motivation due to interoperability problems and abuse for DDoS, and more... Here is (a bit outdated) report on DNSSEC deployment challenges study</div>

<div class="gmail_default" style="font-family:garamond,serif"><a href="http://eprint.iacr.org/2013/254">http://eprint.iacr.org/2013/254</a><br></div><div class="gmail_default" style="font-family:garamond,serif">we plan to upload an updated version soon.</div>

<div class="gmail_default" style="font-family:garamond,serif"><br></div><div class="gmail_default" style="font-family:garamond,serif">Merely deploying DNSSEC as the only solution may have an adverse impact on DNS functionaliy, and functionality and availability of other applications that depend on DNS.</div>

<div class="gmail_default" style="font-family:garamond,serif">I would recommend short term patched (that we recommend in the paper) in the meanwhile, and addressing the deployment challenges of DNSSEC.</div><div class="gmail_default" style="font-family:garamond,serif">

<br></div><div class="gmail_default" style="font-family:garamond,serif">BTW, next week I am in London (presenting our new cache poisoning work at ESORICS), so, if anyone is in the neighbourhood and wants to chat - feel free to drop me a line. The work at ESORICS shows new techniques to deanonymise and cache poison resolvers behind patched upstream resolvers. Following [Kaminsky2008] one of the recommendations of the experts was either to patch or to configure a patched upstream resolver (most notably recommending OpenDNS). BTW, we checked and found many networks to be vulnerable to these new attacks against resolver-behind-upstream. So if you rely only on a patched upstream for your resolver's security, you may want to consider adopting additional mechanisms...</div>

<div class="gmail_default" style="font-family:garamond,serif"><br></div><div class="gmail_default" style="font-family:garamond,serif"><br></div>-- <br><div dir="ltr"><div>Best Regards,<br></div>S.H.<br></div>
</div>