Side note:† In the past I recall you supporting developers "pinning" certificates by rolling their own CAs and bundling the keys with their applications. I have always thought that DANE/TLSA records are an application layer agnostic method for certificate pinning. Do you think I have placed too much trust in DANE?

Given widespread adoption of DNSSEC, DANE records seem like an easier way to manage "certificate pinning" than having to push application updates. Plus I can use the same DANE records that my mobile app uses to protect the third party API for my service. Whereas embedding keys into apps leaves the API unprotected.

I realize "Assuming widespread adoption of DNSSEC" is the big "if" when speaking about the public in general. However for controlled environments (I'm thinking of anything ending in .gov/.mil) DANE records seem like an easy win.

† In this section I am shoveling words into your mouth so I apologize if I have misconstrued/misremembered previous posts.

In the recent discussions about NSA surveillance, a technological anchor we could repeatedly point to was the fact that Google baked the identities of their keys directly into the binaries for Google Chrome. Firefox has adopted the same approach. I don't think it's hyperventilation to suggest that NSA has at least one trusted CA key in its possession, but despite that, NSA probably can't invisibly MITM Google Mail sessions because Chrome's trust anchor for Google Mail isn't a CA certificate.

In a DNSSEC world where DANE was used for key pinning, we'd be back to trusting a PKI root. Moreover, the PKI root we'd most often be trusting is one controlled by the US Government. How, exactly, is that a step forward?

Duh, thank you. I don't know why I was approaching it as if the clients had the DNSSEC keys hardcoded for each zone. It seems that there is not a lot of hope for a solution that is easily interoperable (BYO Browser/MTA) when your threat model includes nation state and sub-nation state threats.