I had this idea a few hours ago, but of course it already exists and there is even an RFC...
Why don't we publish the fingerprint for the SSL/TLS certificate via DNS? We need DNSSEC to make sure the answer is legit and we need to make sure the nameservers are in a secure environment, but besides that I see no issues that SSL/TLS doesn't already have.
This change would move the authority for securing all our encrypted traffic from certificate authorities (CAs) to DNS nameservers. This could be an issue because in that case, all DNS providers (that have DNSSEC) should become very high-security environments like CAs are now. But shouldn't all nameservers already be this? The majority of the websites use plain http for sensitive traffic and most people would not notice if there is no padlock when logging in to Google. I'd say they have a huge responsibility already.
If we don't trust the domain's nameservers, we could include fingerprints in root servers instead, but I'm not sure how much extra load that would be.
Another issue is that DNSSEC is not that widely implemented yet. But the reason for my asking is because the IETF is considering to support encryption in http/2.0 without requiring certificate verification "to make it easier to deploy".
In my opinion, security should either be done correctly or not at all. Don't give people a false sense of security. But if we're going to change protocols anyway (upgrade all webservers), we might as well implement DNSSEC and do this the right (authenticated) way.
The issues/changes in short:
- we need to trust (root?) nameservers instead of a ton of CAs;
- we need to add a dns record type or extend the use of the sshfp record; and
- we need to support dnssec more widely.
Am I missing something? Why are we paying top dollar for SSL/TLS certificates when all we need to do is publish the certificate's fingerprint over some authenticated channel?
The point of unauthenticated encryption in http 2.0 is to encourage enabling it without having to modify any other config at all. I'm against this because it's needlessly slow (another roundtrip for the key exchange, which is especially bad overseas or with any packet loss) and hardly adds any security. It might even provide a false sense of security. On the good side, it obfuscates traffic.
This proposal to use DNS makes it somewhat more work to implement encryption on webservers, but makes it (at least nearly) as secure as normal SSL/TLS while still keeping widespread availability of encryption very high (I don't expect they'll keep up the ridiculously high prices for a sshfp/httpfp/tlsfp-enabled nameserver like they do with certificates). Unauthenticated encryption might still be a last resort when all other options (signed cert; stored cert; securely published fingerprint) are unavailable (though it should not be shown to the user because it provides a completely false sense of security), but I'm not sure it's even worth the slowdown.
If it's not possible to use the root servers for this, we could also use the domain's nameservers as "reasonably secure envionments" (normal padlock) and use a CA-signed certificate for EV (green bar). Then tell people to look for the green bar when they're doing online banking. Nameservers already have a rather big responsibility so it might be safe enough even if we can't expect them to be as secure as a CA. At least it'd be a much more flexible system; I'm restricted to my domain and one subdomain for any reasonably priced certificates (and the subdomain is already occupied by "www.").
My question again in short: Is there any reason why we don't use an SSHFP-like system for https, if DNSSEC were widely available?