3 ms·
One could rightly point out that both of these efforts rely on DNS, which is not secure. Luckily we’ve been working on that problem for even longer than this on
by CWuestefeld 16y ago
One could rightly point out that both of these efforts rely on DNS, which is not secure. Luckily we’ve been working on that problem for even longer than this one, and a reasonable answer is DNSSEC, which enables publishing DNS records that are cryptographically protected against forgery and modification.
This still wouldn't protect against the US government's recent misbehavior. If they actually seize the DNS records, then they can put their own certs into it, too.
I'm not familiar with the details of DNSSEC, so I don't know if it protects against scenarios like in China, where their government controls the DNS. If they can intercept the official DNS records and substitute their own, is there anything preventing them from substituting their own sites, and giving certs that match them?
- agl 16y agoThe current certificate infrastructure already sits on top of DNS. If an attacker can control your DNS then they can get any CA to issue certificates to them because they can accept emails at that domain.
- CWuestefeld 16y agoYes, of course. What I'm wondering about is if (and how) the proposed DNSSEC infrastructure would be superior in this regard.
- tptacek 16y agoThe current certificate infrastructure does not intrinsically depend on DNS. No scheme is resilient against bad actors at the top of the hierarchy; yes, there are (bad) CAs who offer only DNS-equivalent security today. But that's not an SSL/TLS problem; it's a "we should delete CA certs for those CAs" problem.
- CWuestefeld 16y agoWell, to the extent that a cert enables the browser to compare the site's name to its IP address, it is dependent on DNS.