<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small"><span id="gmail-docs-internal-guid-80e358e7-7fff-f652-4dd2-9ec3adb240db" style="color:rgb(0,0,0)"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-ligatures:normal;font-variant-alternates:normal;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Dear researchers, operators and developers,</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-ligatures:normal;font-variant-alternates:normal;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"><br></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-ligatures:normal;font-variant-alternates:normal;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Recently two attack vectors exploiting vulnerabilities in DNSSEC to launch Denial of Service (DoS) against DNS resolvers were publicly disclosed: KeyTrap and NSEC3-encloser attack. Both issues were assigned a CVE ID by MITRE: KeyTrap CVE-2023-50387 and NSEC3-encloser CVE-2023-50868. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-ligatures:normal;font-variant-alternates:normal;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Both attacks proceed as follows: The adversary sets up a domain that it controls and creates a zonefile with specially crafted DNSSEC records. The adversary causes the target DNS resolver to issue DNS requests to a nameserver in its domain, and creates responses. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-ligatures:normal;font-variant-alternates:normal;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">To stall a Bind9 resolver for 16 hours leading to 100% packet loss, one response that encodes a KeyTrap attack is sufficient. As a result of a KeyTrap packet the CPU instruction count on a resolver increases by a factor of 2.000.000x. In contrast, our evaluations of an NSEC3-encloser attack in [1] show that an attack rate of 150 DNS responses per second is required to cause a 5.1% loss of benign packets against Bind9, causing a modest 41x increase of CPU instruction count on Bind9. Increasing the rate of the attack beyond that volume creates too much load on the resolvers leading to packet loss due to system load and not due to specifics of NSEC3 attack. To create packet loss over a longer period that goes beyond one second, the attacker has to constantly send attack packets at a rate of hundreds of packets per second. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-ligatures:normal;font-variant-alternates:normal;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Our evaluations demonstrate that the two attack vectors are fundamentally different from the perspective of their practical impact: KeyTrap introduces a realistic immediate threat for exploitation by hackers. In contrast, with NSEC3-encloser attack a comparable load on resolvers is not possible, not only that with a single NSEC3-encloser attack no packet is lost, but also no latency is introduced to the resolvers. The high volume of NSEC3-encloser attack traffic, of more than hundreds of packets per second, makes the NSEC3-encloser attack visible. Therefore, the high attack volume in tandem with the meager benefit for adversaries (only a small fraction of benign packets dropped) implies that such attacks do not pose a practical threat. </span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-ligatures:normal;font-variant-alternates:normal;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Although we do not expect to see NSEC3-encloser attacks in practice, the topic of zone privacy still requires attention from the researchers, developers and operators, specifically the tradeoff of ensuring privacy against zone enumeration attacks vs. load on resolvers. More details can be found in our paper </span><span style="font-family:Arial,sans-serif;font-size:14.666667px;white-space:pre-wrap">[1].</span><span style="font-family:Arial,sans-serif;font-size:11pt;white-space:pre-wrap"></span></p></span><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small"><br></div><span style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:14.666667px;white-space:pre-wrap">[1] </span><a href="https://arxiv.org/pdf/2403.15233.pdf">https://arxiv.org/pdf/2403.15233.pdf</a><br class="gmail-Apple-interchange-newline" style="color:rgb(0,0,0)"><br class="gmail-Apple-interchange-newline"></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">Best, Haya Schulmann</div></div>