Why? They solve different problems. DNSSEC/DANE moves the TLS CA into the hands of the DNS hierarchy from various corporations. STS just says to use TLS (with this cert, but you can only know the cert is OK to begin with because of a CA, or DANE).
Because the only remaining reason to deploy DNSSEC is to exploit DANE to allow SMTP MTAs to force TLS. All the other uses of DNSSEC are already DOA.
It's a little tricky to explain why this is the case without getting into a lot of gritty detail. A shorthand answer is that browser vendors have, pretty much as a group, decided not to adopt DANE (the DNSSEC-based alternative to the X.509 CA system), and DANE is the only reason anyone cares about DNS security on an Internet where everything is going to be encrypted (usually with TLS) by default.
No, SSHFP is pretty silly as a motivating use case for DNSSEC. There's nothing it does that you can't do (better!) with some other system. It makes sense if you already have a secure DNS. But that begs the question of why you would need a secure DNS.
You don't need a secure DNS for the web.
You don't, with STS deployed, need a secure DNS for email.
Is publishing SSH key fingerprints so important that we should do a forklift upgrade of the DNS? No, of course not.
STS information is stored in DNS records. Why would you not want to secure those?
Also, I think you're underestimating the growth of DNSSEC deployments. I've been watching DNSSEC growth for about 2 years and it is steadily moving up and to the right.
It has taken two decades to get to this point. The protocol has been substantially revised four times, and, after each of those four revisions, DNSSEC proponents said "now, we've got it right, and it's ready for universal deployment".
It is nowhere near ready for universal deployment today, and, indeed, virtually nobody relies on it, unlike TLS.
DNSSEC ain't pretty. I'll agree with you there, but that doesn't mean it isn't the best thing going for us in terms of securing the DNS. Like it or not it's important to be able to trust DNS responses.
I guess I don't have some expectation that deployment should take place quickly. Or that the first go at a protocol is going to always get it right. Just because a journey is difficult doesn't mean the journey isn't worth taking.
DNSSEC and TLS are unrelated. They're trying to solve different problems.
It absolutely is a legitimate use case, and would IMO improve security for the type of developers who do use SSH, but don't know what a fingerprint is. It would also make it easier to create secure connections for non-developers, e.g. a SFTP/SCP based file sync app.
I don't have good numbers for signing of zones. Although we do know that these numbers are increasing. Cloudflare recently turned on DNSSEC for all of their clients.
> It is a selling point in that it simplifies the protocol, making it easier to implement.
In the current protocol the only difference between offline and online signing is in how authoritative servers are implemented. There the differences aren't all that significant (relative to building an authoritative server as a whole) -- the same data needs signing, etc -- so please explain how your protocol makes implementation simpler.
> Obviously it would not be the only difference.
Can you please expand on that? You've said you've been thinking of a DNSSEC2 proposal for a while so you must have more to say.
I forgot to mention that one of the known problems of DNSSEC is the DNS zone information disclosure problem. Online signing would allow the problem to be eliminated and reduce complexity by the protocol no longer having to be designed for enumerating DNS records. Of course, DNSSEC2 would probably only allow ECC signing too (I suggest both NIST curves and Curve25519 as options).
Online signing and white lies are already in DNSSEC. What you've described so far doesn't seem to be different to the status quo. Even deprecation of older cryptographic signatures is being worked through at the moment.
You have said you have been thinking of a DNSSEC2 proposal for a while, that your protocol differs in multiple ways and that it is easier to implement. Given this you should be able to concretely articulate how your protocol differs and where its advantages are gained. Thus far you have not shown the ability to do this.
