[tptacek]

The existence of SRV records does not mean DNSSEC provides the same functionality as HSTS, and you yourself have already explained why. You're moving the goalposts. The argument you're rebutting is "it would be impossible to implement HSTS in DNSSEC". I didn't make that argument. My argument is: even if DNSSEC were widely deployed tomorrow, we would still need HSTS. I'm right about that.

Plan B is "do nothing". That would be a crazy plan if DNSSEC did something to solve the CA problem. It doesn't. It adds a 1483rd CA to the trust model that is heavily influenced by NSA.

Not one person has presented a coherent rebuttal to this point, despite virtually every DNSSEC proponent starting their response to my criticism "DNSSEC is not a government controlled PKI". Their arguments are all uniformly: "DNSSEC is not a government controlled PKI, except for the places like .COM and .IO, where that's exactly what it is".

[nly]

> My argument is: even if DNSSEC were widely deployed tomorrow, we would still need HSTS. I'm right about that.

You are, but my argument is, even if HSTS reaches 100% adoption, we still need something else.

> That would be a crazy plan if DNSSEC did something to solve the CA problem. It doesn't. It adds a 1483rd CA to the trust model that is heavily influenced by NSA.

It's naïve to think the NSA don't already have keys to a whole bunch of trusted CAs. The NSA are irrelevant to this discussion. When it comes to rogue CAs or system compromise however, having 1 CA to trust is better than X hundred. And, iirc, current browsers rightly ignore HSTS/HPKP for self-signed certs without an additional trust anchor (like DNS pinning).

Around and around we go, avoiding the key point. It's all about who you want to trust.

[tptacek]

This debate plays out like a go joseki. Predictably, we've reached the part where the pro-DNSSEC side says, in effect, "NSA controls the Internet anyways, so it doesn't matter if we give them more control".

Sorry, I have a problem with the deployment of entire new Internet cryptosystems that grant NSA huge privileges by design. A decade of crypto engineering may have instilled an irrational bias against broken, compromised cryptosystems. To me: crypto should be something that makes NSA's job harder, not easier.

We may be at an impasse.

[nly]

I'm on your side, really. It's only my cynicism that puts me on the 'fuck it, if we're going to have DNSSEC let us at least leverage it well' side of the fence. That's exactly the same attitude as HPKP and HSTS in HTTP: 'Well HTTP sucks, let's see what we can do'.

[cpach]

> The NSA are irrelevant to this discussion.

NSA certainly is a resourceful adversary. But may I point out what Thomas wrote in his FAQ about this?

”If over the next 5 years nothing more is done to shore up Internet security than is already being done, targeted CA-based attacks will become much riskier for NSA and GCHQ because of key pinning. To man-in-the-middle an HTTPS connection, NSA will need to know that the browser they’re targeting hasn’t already cached the correct key fingerprint for the server. If it has, the browser will scream bloody murder and, hopefully, report back to Google or the EFF about the discrepancy. People watching those logs will quickly discover which CAs are signing bogus certificates, and compromised CAs will be evicted from browsers. NSA and GCHQ will have to risk burning an entire CA every time they launch this attack. If we do nothing new at a protocol level, every Chrome and Firefox installation on the Internet will become part of a global anti-surveillance surveillance system.”

http://sockpuppet.org/stuff/dnssec-qa.html