[aianus]

How does having a new super-CA controlled by the NSA impede key pinning and certificate transparency?

I agree that CAs + DANE is just as shitty or shitter than CAs.

But:

a) In the event DANE replaced the CA system, one super-CA controlled by the NSA is better than 300 CAs essentially controlled by 50 different governments including the NSA.

b) Nobody's making you use DANE. Signed DNS records are an improvement over the status quo regardless of what you think of tying TLS to it.

[tptacek]

No. (a) is wrong.

The difference between DNSSEC's government-controlled super CA and a normal TLS CA is that when Google spots a normal TLS CA misbehaving because of an alert from a broken pin or CT log, it can shitcan the CA, either evicting it from the trust store or placing onerous restrictions on it. Both of these things have happened and will keep happening.

Google cannot do that to .COM or .IO. If the government-controlled super-CA that runs .COM misbehaves, we have no recourse.

DNSSEC essentially takes the worst feature of the HTTPS trust model and bakes it permanently into the core fabric of the Internet.

[throwaway2048]

reposting a comment:

What do you think would happen under a DNSSEC-DANE TLS world if that started being detected via key pinning/CT ?

There is just no way the NSA is going to risk it except in very very specific circumstances they can easily control, (exactly the same situation as HPKP) because, they too will be forever burned just like an ssl CA would, except now they cant just switch to one of hundreds of other CAs, they have burned the root keys to a tld. This will be obvious, this will be screamed about from the rooftops, the key will be rotated + a ton greater scrutiny applied to the process.

Its not like browsers and other people pinning certs are just going to shrug their shoulders and say "aw shucks, i guess we wont worry about it"

[hueving]

And how exactly do you think rotating a TLD key will help if it's obvious that TLD will just give the new key to the NSA anyway?

[throwaway2048]

the same way it can help in the case of the CA, parties like Google will set strict standards + see them compiled with or DANE etc will be ignored from the suspect TLDs.

[tptacek]

What does it mean to "set strict standards" on .COM? Google can eliminate whole CAs, or scope them down to only a subset of names. It can't do that with .COM.

[throwaway2048]

it can however refuse to allow DANE to be used on .COM/other TLDs + apply immense political pressure.

[aianus]

> it can shitcan the CA, either evicting it from the trust store or placing onerous restrictions on it

None of which prevents it from happening again with another one of the 300 CAs whenever another government gets antsy.

> If the government-controlled super-CA that runs .COM misbehaves, we have no recourse.

As a westerner I trust the super-CA that runs .COM 1000x more than some random CA in China or Iran or whatever. But even that's beside the point. If they abused their trust (which would be caught by CT) the whole system would collapse because, like you said, you can't shitcan .COM. Everyone would move to keypinning and/or a decentralized blockchain-based DNS solution and we would gain real security.

[tptacek]

One thing I love about DNSSEC threads is that I get to join the anti-NSA faction on HN. Unlike you, I do not trust the giant corporation that controls .COM under charter from the US Government.

The USG has repeatedly abused its trust, often directly with respect to .COM. The Internet has not fled .COM.

The idea that we would deploy a forklift upgrade of a core protocol, at immense expense (look at Cloudflare's own marketing material!), ostensibly to improve security but in reality to put ourselves in the position of "fleeing .COM IF the US Government abuses it trust", boggles my mind.

The problem DNSSEC purports to solve is not cryptographically hard. DNSSEC made it hard because it was designed in 1995, at a time when designers felt it would be implausible for DNS servers to sign records.

We are talking about deploying this fiasco of a protocol with all its compromises purely because of the momentum of a 21+ year long standardization effort. Once we deploy it, any notion of solving the problem correctly dies. That's a terrible, terrible mistake.

[jessaustin]

Once we deploy it, any notion of solving the problem correctly dies.

This seems to be the nut of the disagreement. Why do you expect that to be the case? Will good people like Marlinspike decide to just hang it up and throw in the towel now that CloudFlare have rolled out another service? Will CloudFlare themselves decide this is the last new security measure that anyone would ever want?

So far I have seen no technical reason why DNSSEC inhibits development of possibly more worthy security techniques. Sociological arguments are less convincing.

[tptacek]

I don't know. Why don't you ask Moxie Marlinspike, who frequently comments on HN, what he thinks of DNSSEC?

[jessaustin]

His comments are noted. They don't seem to include, "we're shutting down Convergence and Tack now that CloudFlare have rolled out DNSSEC."

Can you cite a technical reason why DNSSEC inhibits development of possibly more worthy security techniques?