In light of recent attacks on SSL/TLS communication, people have been asking about ways to improve the security of SSL webserver communication. Several great solutions have been mentioned in the following links (example 1, 2, 3 and blog posting).
There is a general agreement that if a network administrator uploads the website's SSL public key (or its hash) into DNS, security could be improved
The drawbacks of the proposed solution is that:
All recommendations for this particular solution require DNSSec, which adds complexity and has a cost associated with it.
Client software (browsers, Operating Systems) will require an update to actually check DNS for certificate information
In the spirit of providing immediate relief to the very broad security issue at hand, I'm questioning the assumed requirement of DNSSec. By removing this requirement, and simply allowing the website owner to dictate the SSL intermediates (or specific public keys) they want to use via DNS, we allow the content publisher (or e-commerce site) to declare what is trusted, and therefore make some attack vectors much (much) more difficult to overcome.
Is DNSSec required for public key/hash distribution?
- According to this link, DNS hacking is not a concern for the majority of users on the internet. Notable exceptions include WiFi users and certain SoHo routers are of concern. If DNSSec is only needed for these edge cases, why delay implementation for a borderline technology?
Are there any threat models comparing using regular DNS as a repository as opposed to DNSSec?
- The premise of this question assumes that although using regular DNS is imperfect, it does make great strides protecting users against a general, system-wide vulnerability.
What should be stored, the hash, or the full public key?
How difficult would it be for vendors to support this extra validation of a SSL/TLS certificate?