1. Pull the public key from DNS to add to ~/.ssh/authorized_keys
2. Implement an sshd runtime that checks the DNS record rather then (or in addition to) ~/.ssh/authorized_keys
Sure, it's "just" the public key so you're not providing the private key to the world-at-large, but if the NSA controls DNSSEC, then they can change the public key to one that is paired with a private key that they control. Now they have access to all systems that the public key could access. This is basically adding DNSSEC as an attack vector to your ~/.ssh/authorized_keys file, which seems like a bad idea.
Please correct me if I'm missing something about how DNSSEC and SSH keys would be used together.
http://tools.ietf.org/html/rfc4255
When you first connect and get the SSH fingerprint, how many people truly validate through some other mechanism that this is the correct public key to use for some system? (I have on some systems but I know I have just accepted the public key on other systems.)
The idea is to use DNSSEC and the SSHFP record to provide a mechanism to validate the SSH public key.
Do note this is not a new idea. This RFC was published back in 2006.
With DNSSEC, they'd have to subvert the entire DNS infrastructure, signed from the top all the way down to the particular domain they want to falsify. But it is somehow this infrastructure you wish to label "NSA controlled"?
But that's not the point. The only point is that between it and the SSL CA infrastructure, the latter is the one NSA has more control over and a much easier time generating certificates for, so the labelling the former "NSA controlled" is slightly disingenious.
Any such argument would be valid for pretty any global PKI system, if the argument is that they control important parts of the Internet infrastructure. The SSL CA system is even more controlled by the NSA as DNSSEC is.
DNSSEC is much harder to circumvent than the SSL CA system, no matter how you look at it.
So I do not mean to refute that the NSA controls the Internet, the CA system, and DNSSEC (even if I don't believe that's an accurate description). It is simply not a meaningful discussion to have. Even if the NSA can break the Internet, there are other use cases and it still carries great value for everyone.
Perhaps I should thank you, Thomas, for continuing to beat this drum... because it shows extremely clearly how we need to educate more people and be MUCH more clear about exactly how the keys at the root of DNSSEC are maintained. If people fully understand the process, and how it was designed to NOT allow attackers in this way, we could spend our time on much more productive discussions. (Granted, documents such as https://www.iana.org/dnssec/icann-dps.txt do NOT make for friendly reading.)
Thank you for pointing out the work that needs to be done.
You are advocating for a PKI that is literally shrink-wrapped around government-controlled namespaces. For a security protocol on the global Internet, that's an utterly unforced error. It boggles my mind that anyone had ever considered it, and I am thankful that it is a dead letter now.
Again, that's the point. You keep pointing out that DNSSEC is somehow government controlled, when what you really mean is the entirety of DNS and CAs put together are, and not specifically just DNSSEC. That doesn't make for a constructive discussion since there is no context of an alternative system. Status quo still leaves us with easily falsified domain validated certificates.
I can agree for the sake of discussion that the DNS and CA system is under government control. So against an intelligence organization with unlimited resources anything built on DNS or certificates would fall, so DNSSEC wouldn't help you there. But against every other attacker in the world it absolutely would (while making the attacks it can't defend against easier to detect).