[Cryptography] In code we trust, hybrid PQ and the rehabilitation of DANE

[Shreyas Zare]

On 5/2/2026 11:50 PM, Andrew Lee wrote:
> 3. DANE
>
> 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.
>
> 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.
>
> In bmail's setup, the TLSA record at _25._tcp.smtp.bmail.ag 
> <http://tcp.smtp.bmail.ag> 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.
>
> 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.
>
> 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!
>
> To be clear, the TLD can still lie, but good SMTP servers won't deliver.
>
> The Great DANE is a good boy. :)


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.

If anyone is interested they can read it here: 
https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-is-needed.html

Regards,
*Shreyas Zare*
Technitium <https://technitium.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20260505/835f0ba2/attachment.htm>