[dns-operations] BlackHat Presentation on DNSSEC Downgrade attack

[Haya Shulman]

We allowed Peter Thomassen and Nils Wisiol to join our research. We are
also not aware of any contributions they made. We removed both colleagues
from our research. In fact, to Peter Thomassen we sent an email in November
2021 on behalf of all the senior researchers on this project, suggesting to
him that since his contribution did not justify authorship it would be
ethical to remove himself from the authors’ list. He refused.

If Mr Thomassen wanted to remove the arxiv paper version, it is surprising
that he himself published the link of the arxiv paper to this list....

We wanted to remove the arxiv paper to replace it with a version without
the two colleagues, however, we have not received their consent, which
arxiv requires for removal of uploaded papers. Therefore, the current
version is only "withdrawn", meaning, it is still available online.


I also suspect Peter Thomassen might not have fully understood our research
he wanted to join, esp. given his questions: "this allows "downgrade" to
"weakest" (whatever that means)": in our project we evaluated two ways to
downgrade DNSSEC, by disabling validation and by downgrading to a weaker
cryptographic algorithm.

On a different note, if DNSSEC used only one algorithm or a fixed set of
algorithms, implementing this would have been simpler and our attacks would
perhaps not apply. The different vulnerabilities are caused by an attempt
to allow replacing and adding new algorithms. In some cases the
recommendations are vague, while in other cases they lead to problems even
if one avoids implementation bugs, e.g., during key rollover. Analysis of
the different problems leads to one root cause: the current algorithm
agility in DNSSEC is what allows our attacks. [RFC7696] says "Algorithm
agility is achieved when a protocol can easily migrate from one algorithm
suite to another more desirable one, over time." - The ability to migrate
from one algorithm suite to another in the current implementations is what
exposes DNSSEC to our attacks.

In general, I recommend for questions about our work to follow the official
announcements and tools of our group. Elias Heftrig, who leads this project
as part of his PhD work, is setting up a website (like we typically do in
our research projects) with explanations and a tool for checking
vulnerabilities, which anyone can use. If there are questions or comments,
please email them to us, since I am not following mailing lists.

I will also use this opportunity to add pointers to other DNS related
research projects of our group, which may be of interest to this audience:

* In a recent USENIX Security 2022 research we showed that DNS forwarders
in residential routers introduce a vulnerability and demonstrated attacks
exploiting them. We did black box and white box analyses of popular
routers, finding many to be vulnerable. Philipp Jeitner (just graduated
PhD) set up a tool which you can use to check if your routers are
vulnerable. More details here:

https://www.usenix.org/conference/usenixsecurity22/presentation/jeitner

* In a recent ACM CCS 2022 research we explored the dependency of RPKI
deployments on DNS and the impact of DNS resolvers and nameservers on the
resilience of RPKI deployments. We evaluated how attacks against DNS can
subvert RPKI validation. This research will be presented in November 2022.


Best, Haya Shulman


--

Prof. Dr. Haya Shulman

Goethe-Universität Frankfurt

Fraunhofer SIT

ATHENE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220822/fcfdedec/attachment.html>