4 ms·

DNSSEC doesn't create or diminish any trust in ccTLDs that wasn't already there. The Libyan government has all the authority to mess with .ly, it's their ccTLD.

DNSSEC doesn't create or diminish any trust in ccTLDs that wasn't already there. The Libyan government has all the authority to mess with .ly, it's their ccTLD. Without DNSSEC the Libyan government can mess with .ly, and with DNSSEC the Libyan government can mess with .ly. The main difference is that with DNSSEC, if someone does mess with .ly you know it was the Libyan government. Without DNSSEC attribution of the messing-with becomes much more difficult. I think we both agree that there are innate problems with hierarchies of trust. Unfortunately, for better or for worse, we're stuck with hierarchies until something better comes along. Let's also not make perfection the enemy of good, Namecoin, or other massively distributed naming systems, might eventually develop into really interesting technologies. However, for the immediate future, we're stuck with DNS and we should make the most of it.

tptacek 12y ago
No. The Libyan government does not have the authority to surreptitiously control BIT.LY. That's not how the Internet trust model works. Even in the badly broken implementation we have today, there are things BIT.LY can do to override Libya; for instance, they can have their certificate pinned to a specific trusted CA. The general belief that TLD managers "already" control sites is probably behind a lot of otherwise- inexplicable DNSSEC boosterism. Because if you really believe that, then sure, giving still more control to the operators of those TLDs is just a cosmetic change. But, thankfully: no. No, no, no. The operators of .COM don't get to monitor Google mail. The government of the British Indian Ocean Territories doesn't get to patch Redis. The schemes we have now to fence Internet trust off from TLDs are imperfect. The right response to that is to make them better. DNSSEC advocates act like this is a pipe dream, but there are surprisingly simple things we can do right now to massively improve the situation, like adopting TACK or HPKP to turn everyone's (or at least everyone running Chrome and Firefox's) browsers into a surveillance system for attempts to compromise Internet trust. "But we can do this in a DNSSEC world, too", the DNSSEC advocates say. That's not quite right; they mean to say, "but we still have to do this in a DNSSEC world". Two problems. First, if we're going to rely on HPKP/TACK and CT as a bridge to a decentralized reasonable trust system, why waste the time and effort on DNSSEC in the first place? Answer: there is no compelling reason to do that. Secondly: DNSSEC actually makes it harder to do those things; among the reasons, when TLD operators misbehave, there is no recourse at all for rectifying the situation. How long do you think it takes the Chrome team to flip the switch to remove a rogue CA? Now, how long will it take them to remove .COM?

tptacek 12y ago

No. The Libyan government does not have the authority to surreptitiously control BIT.LY. That's not how the Internet trust model works. Even in the badly broken implementation we have today, there are things BIT.LY can do to override Libya; for instance, they can have their certificate pinned to a specific trusted CA. The general belief that TLD managers "already" control sites is probably behind a lot of otherwise- inexplicable DNSSEC boosterism. Because if you really believe that, then sure, giving still more control to the operators of those TLDs is just a cosmetic change. But, thankfully: no. No, no, no. The operators of .COM don't get to monitor Google mail. The government of the British Indian Ocean Territories doesn't get to patch Redis. The schemes we have now to fence Internet trust off from TLDs are imperfect. The right response to that is to make them better. DNSSEC advocates act like this is a pipe dream, but there are surprisingly simple things we can do right now to massively improve the situation, like adopting TACK or HPKP to turn everyone's (or at least everyone running Chrome and Firefox's) browsers into a surveillance system for attempts to compromise Internet trust. "But we can do this in a DNSSEC world, too", the DNSSEC advocates say. That's not quite right; they mean to say, "but we still have to do this in a DNSSEC world". Two problems. First, if we're going to rely on HPKP/TACK and CT as a bridge to a decentralized reasonable trust system, why waste the time and effort on DNSSEC in the first place? Answer: there is no compelling reason to do that. Secondly: DNSSEC actually makes it harder to do those things; among the reasons, when TLD operators misbehave, there is no recourse at all for rectifying the situation. How long do you think it takes the Chrome team to flip the switch to remove a rogue CA? Now, how long will it take them to remove .COM?