I'm not sure you understand what the post was suggesting. All it was suggesting is that instead of validating the SSL certificate sent by using the hardcoded certs in the browser, it's validated by doing a DNS lookup to retrieve a hash of the cert. Where DNSSEC is used to "secure" the validity of that lookup.
It could even be an addition to the protocol, so the validation is done as normal with the CA's certificates which are hardcoded in the browser, but then a DNS lookup is done as well. That would defend from unscrupulous CA's that create additional certificates for a domain and give them to government organisations.
The original post was suggesting that we augment SSL by using DNSSEC to distribute cert authenticators instead of CAs. I'm saying that, for a lot of reasons, grafting DNSSEC onto web security is a solution far inferior to simply keeping TLS and solving the UI and policy problems we inevitably need to solve anyways.
Some of the problems are inherent in having multiple trusted CAs, or third-party CAs. These can be mostly solved by merging the CA function into DNS, or (almost) completely solved by something like Perspectives.
Problems being:
* someone who wants a fake cert, can go shopping for the worst CA available. You as a site owner cannot specify a CA.
* in order to have a cert on your site, you have to pay off a third party. Otherwise the browsers will scream at your visitors that unknown https is more insecure than plain http. ubiquitous encryption requires that certs come "for free" with what you need to just have a presence (such as being bundled with the domain name because they're just an extra DNS record).
It is, I think, a little crazy to suggest that a very simple configuration problem with the best-tested security protocol on the Internet should be solved by a complete overhaul of a different core Internet protocol.
Comments
I'm not sure you understand what the post was suggesting. All it was suggesting is that instead of validating the SSL certificate sent by using the hardcoded certs in the browser, it's validated by doing a DNS lookup to retrieve a hash of the cert. Where DNSSEC is used to "secure" the validity of that lookup.
It could even be an addition to the protocol, so the validation is done as normal with the CA's certificates which are hardcoded in the browser, but then a DNS lookup is done as well. That would defend from unscrupulous CA's that create additional certificates for a domain and give them to government organisations.
The original post was suggesting that we augment SSL by using DNSSEC to distribute cert authenticators instead of CAs. I'm saying that, for a lot of reasons, grafting DNSSEC onto web security is a solution far inferior to simply keeping TLS and solving the UI and policy problems we inevitably need to solve anyways.
Some of the problems are inherent in having multiple trusted CAs, or third-party CAs. These can be mostly solved by merging the CA function into DNS, or (almost) completely solved by something like Perspectives.
Problems being: * someone who wants a fake cert, can go shopping for the worst CA available. You as a site owner cannot specify a CA. * in order to have a cert on your site, you have to pay off a third party. Otherwise the browsers will scream at your visitors that unknown https is more insecure than plain http. ubiquitous encryption requires that certs come "for free" with what you need to just have a presence (such as being bundled with the domain name because they're just an extra DNS record).
It is, I think, a little crazy to suggest that a very simple configuration problem with the best-tested security protocol on the Internet should be solved by a complete overhaul of a different core Internet protocol.