<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 5/2/2026 11:50 PM, Andrew Lee wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACSbMKmNtJwro8=xQ2=xhp5cKC2cARc4hRWBstG9mt22+0OzVQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">3. DANE<br>
<br>
The honorable tptacek famously argued the falacies of DNSSEC's
verification model insofar that it concentrates power in TLD
operators/registrars, and said TLD/registrars answer to
governments. On its own, DANE is a weak root of trust with
minimal benefits over the existing WebPKI.<br>
<br>
I agree with his analysis. However, DANE has other uses cases
that provides for a myriad of opsec and verificational
benefits. As a root of trust, DANE could improve. As a
validator, DANE mogs.<br>
<br>
In bmail's setup, the TLSA record at _25._<a
href="http://tcp.smtp.bmail.ag" moz-do-not-send="true">tcp.smtp.bmail.ag</a>
is the SPKI hash of a key generated inside the smtp-inbound
enclave on first boot, which is sealed under MRENCLAVE. The
enclave posts the hash + a fresh quote to a gated API which
validates the full Intel chain and confirms the MRENCLAVE
matches a published smtp-inbound build before writing the
record.<br>
<br>
Gmail, Outlook, and any other DANE-aware MTA refuses to deliver
mail to bmail unless the served cert matches that hash. The only
server in the world that can present the matching SPKI is the
exact MRENCLAVE we published since it is the only one who has
the key.<br>
<br>
DANE earns a reason to exist here as a third-party-validation
channel that says "the box answering on port 25 really is the
binary" that the protocol actually speaks. We used this to chain
SGX verification to SMTP!<br>
<br>
To be clear, the TLD can still lie, but good SMTP servers won't
deliver.<br>
<br>
The Great DANE is a good boy. :)</div>
</blockquote>
<p><br>
</p>
<p>The arguments made against DNSSEC are pretty much obsolete and
have logical fallacies of their own. I had written a blog post a
few years back that discussed most of the argument made against
DNSSEC with context of DANE. </p>
<p>If anyone is interested they can read it here:
<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></p>
<div class="moz-signature">
<p>Regards,<br>
<b>Shreyas Zare</b><br>
<a href="https://technitium.com/">Technitium</a>
</p>
</div>
<p><br>
</p>
</body>
</html>