<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 4/24/2025 12:58 AM, Jon Callas
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:B01FB1C5-7318-46CA-AD35-8A92958B5F88@callas.org">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">On Apr 23, 2025, at 07:10, Kent Borg <a class="moz-txt-link-rfc2396E" href="mailto:kentborg@borg.org"><kentborg@borg.org></a> wrote:
On 4/22/25 8:32 PM, Paul Wouters wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">All the CAbal exists only because of browsers refusing to do DNSSEC,
even now they have a clean and secure path via DoH anyways....
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
What are the downsides to DNSSEC? Both honest and real, and imagined or excuses.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
If you haven't read Tom Ptacek's "Against DNS" <a class="moz-txt-link-rfc2396E" href="https://sockpuppet.org/blog/2015/01/15/against-dnssec/"><https://sockpuppet.org/blog/2015/01/15/against-dnssec/></a>, you should. While not every one of his comments are things everyone agrees with, the points are all well-argued. </pre>
</blockquote>
<p>I had written a rebuttal to "Against DNSSEC" and the followup
blog post by Thomas Ptacek a couple of years ago in this blog post
titled "For DNSSEC And Why DANE Is Needed" (<a class="moz-txt-link-freetext" href="https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-is-needed.html">https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-is-needed.html</a>).
It covers most arguments made against DNSSEC and more.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:B01FB1C5-7318-46CA-AD35-8A92958B5F88@callas.org">
<pre wrap="" class="moz-quote-pre">The objection that is most apropos is outlined again here, <a class="moz-txt-link-rfc2396E" href="https://infosec.exchange/@tqbf/109938525731567458"><https://infosec.exchange/@tqbf/109938525731567458></a>, that it is just another PKI and one where the CAs are the top-level-domain owners -- governments. Thus, for example, if you have a domain in `.ly`, your CA is the government of Libya. For `.io`, it's whoever is in charge of that -- be it the British government, Mauritius, or private sector actors operating with the cooperation of one, the other, or both.
It's thus completely possible for that owning government to have an alternate DNSSEC and flip between them at will. John Gilmore reminded us of the QUANTUM <thing> projects done in the past, and DNSSEC makes the concept possible with a new implementation.</pre>
</blockquote>
<p>The "government" argument is really poor. DNS is a government
controlled entity and they can, if they want to, get an SSL/TLS
cert for any domain name anyways. They control the TLD which means
they can delegate a request from a specific IP or network range to
different name servers on IP addresses they control and get the
cert with domain validation.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:B01FB1C5-7318-46CA-AD35-8A92958B5F88@callas.org">
<pre wrap="" class="moz-quote-pre">The present WebPKI system requires an attacker to both gain control of the certificate system and compromise the network access. Sometimes this is easy -- we've discussed a rogue hotspot. Sometimes it's not easy. One can argue that an evil DNSSEC root is only a single thing that's harder to do, which means to me that it is at best shuffling the cards, and not changing the game.
We can (and I am sure will) debate this here at length, but that's the essence of the argument, that you're changing out one PKI for another.</pre>
</blockquote>
<p>Its not exactly correct. Its changing out 100s of CAs with just
one that the TLD controls.<br>
</p>
<div class="moz-signature">
<p>
Regards,<br>
<b>Shreyas Zare</b><br>
<a href="https://technitium.com/">Technitium</a></p>
</div>
<p></p>
</body>
</html>