>Instead, update the browser UX, which is the only thing leaving us hostages to the CA system.
This is only the case if you mean the browser UX as it relates to site owners and not site users. For users the only browser UX they should need to know about is the browser being able to tell them with confidence "this communication is [not] secure".
So why go through all this hackery to patch up the broken CA system vs just distributing the TLS keys through DNSSEC? That way you get a complete chain of trust all the way to the DNS root, validating both HTTP and the initial DNS response. Then you can really tell the user that the communication is tamper-proof without any gotchas about rogue CAs and certificate pinning.
DNSSEC is just another PKI, but this time controlled by world governments. I'm baffled by how anyone could think that DNSSEC is a superior alternative to the CA system.
The good news about DNSSEC is that it's never going to happen anyways.
Meanwhile, TACK strikes a balance between the convenience/stability of having a third-party trust anchor that can vouch for your identity, while at the same time putting site owners in control of how strong that voucher is, by allowing them to bind their identity directly with clients. You could in theory pin a self-signed certificate, if that was your thing.
>DNSSEC is just another PKI, but this time controlled by world governments. I'm baffled by how anyone could think that DNSSEC is a superior alternative to the CA system.
We rely on DNS anyway so what can those world governments do with a DNSSEC PKI that they can't do with DNS as is? I mean if you can change the DNSSEC distributed certificate for google.com surely you can just redirect google.com and be done with it.
No. We do not rely on DNS now. The whole design of TLS is premised on the notion that the DNS is insecure. Much to NSA's annoyance, if I switch MAIL.GOOGLE.COM in the DNS, I cannot easily MITM people's Gmail sessions.
>Much to NSA's annoyance, if I switch MAIL.GOOGLE.COM in the DNS, I cannot easily MITM people's Gmail sessions.
If the user is using a new browser or has an expired HSTS header, wouldn't it actually be trivial to do? Or are you also relying on TACK to say "never connect to mail.google.com without TLS" or on HTTP/2.0 to mandate TLS everywhere?
My assertion is that absent some way to force TLS from the start on the connection owning DNS allows you to MITM a user that types mail.google.com in the address bar. Where is that wrong?
If you don't distribute the pin along with the browser you don't get TLS forced on the first connection. As you yourself said in the other thread TLS+TACK doesn't solve this either. So this is hardly a fundamental property of TLS.
Browser trust anchors aren't a fundamental property of HTTPS/TLS? That's like saying "TLS is insecure if you don't distribute any root certificates with your browser".
Really? You're arguing that a feature that was first implemented in 2011 is a fundamental property of TLS? And are you also arguing that the whole web should have Google/Firefox/IE/Safari ship a certificate pin with the browser? That will surely scale...
If we're doing that why do we need CA's at all? Just ship pins of self-signed certificates to all the browsers and trust Google with the integrity of the database.
This is true but those governments already control the domain name system, so they can yank or redirect your domain. You're already trusting the registry so why not have them sign your certificate? There's nothing stopping your from pinning it later, too.
Also, that way you could limit your trust to one entity per tld. Unlike today where any CA anywhere in the world can sign any certificate.
I feel like I have to keep saying this over and over: no, you do not rely on the domain name system for security. TLS was designed to assume that the DNS was totally insecure.
Yes, world governments can yank GOOGLE.COM so you can't reach it at all. But what they can't easily do is stand up a different MAIL.GOOGLE.COM and reliably collect people's mail.
However, if were were stupid enough to stick TLS certificates into the DNS...
The trouble with the idea that TLS assumes DNS is "totally insecure" is the numerous CAs that will issue certs based on proof of control over the domain name -- as observed by the CA.
So while TLS itself doesn't trust DNS at all, PKIX does! CAs may well have google.com on a blacklist, but if someone could "yank" matasano.com and point it at their own server, they could most likely get GoDaddy to issue them a cert based solely on their control over that server. GoDaddy's existing test for the legitimacy of a certificate issuance request is the ability to post a text file with specified contents on an HTTP server pointed to by the subject CN.
(For that matter, the attacker who took control of the matasano.com zone could then publish MX records allowing them to intercept any verification or confirmation e-mails to the whois contacts.)
I agree that the model doesn't work at all right now without pinning, though for the adversaries I'm concerned about, it's still strictly better than DNSSEC.
Without pinning, keys in authenticated DNS (like with DANE) are strictly better than CA certificates, because the CA certificates are themselves issued on the basis of (even unauthenticated!) DNS data.
I find it hard to believe that a government agency couldn't easily present a forged certificate perceived as valid by popular browsers if they were so inclined.
Couldn't you also pin a certificate if it was distributed over DNS? DANE would make setting up ssl simpler for operators of small sites while not compromising the ability of big players, like Google, to deploy their own security mechanisms.
This is only the case if you mean the browser UX as it relates to site owners and not site users. For users the only browser UX they should need to know about is the browser being able to tell them with confidence "this communication is [not] secure".
So why go through all this hackery to patch up the broken CA system vs just distributing the TLS keys through DNSSEC? That way you get a complete chain of trust all the way to the DNS root, validating both HTTP and the initial DNS response. Then you can really tell the user that the communication is tamper-proof without any gotchas about rogue CAs and certificate pinning.