> In practice, TLS certificates are given out to domain owners, and domain ownership is usually proven by being able to set a DNS record. This means compromise of the authorative DNS server implies compromise of TLS.

Yes, except for CT, which can help detect this kind of attack.

> Malicious relaying servers and MitM on the client is already solved by DNSSEC, so it's not adding anything there either.

I'm not sure quite what you have in mind here, but there is more to the issue than correct DNS resolution. In many cases, the attacker controls the network between you and the server, and can intercept your connection regardless of whether DNS resolved correctly.

> If we got rid of CAs and stored our TLS public keys in DNS instead, we would lose relatively little security. The main drawback I can think of is the loss of certificate issuance logs.

This may be true in principle but has a very low chance of happening in practice, because there is no current plausible transition path, so it's really just a theoretical debate.

▲

cyphar a day ago | parent [-]

> This may be true in principle but has a very low chance of happening in practice, because there is no current plausible transition path, so it's really just a theoretical debate.

Well, DANE exists and provides an obvious transition path, as brittle of an approach it is. Ideally you would be able to create your own intermediates (with name constraints) and pin the intermediate rather than the lead certificate, but PKI isn't set up for that.

From my understanding, the biggest issue with DNSSEC is that it's just a return to the single signing authority model that TLS used in the 90s. Isn't it also just Verisign again? (At least for .com.)

	▲	tptacek 2 hours ago \| parent [-]
		That is a problem, but beyond the philosophical problem (which I care a lot about) and the cryptographic problems (which I care a lot about), most of the reason DANE isn't taken seriously (is, in fact, a dead letter with the browsers, meaning it's a dead letter everywhere) are practical issues deploying it. Stipulate, very unrealistically, that a sizable portion of the most popular zones were signed (the opposite is true). Then: You still have the problem where a substantial cohort of Internet users can't resolve DANE records. They're on Internet paths that include middleboxes that freak out when they see anything but simple UDP DNS records. You can't define that problem away. So now you need to design a fallback for those users. Whatever that fallback is, you have to assume attackers will target it; that's the whole point of the exercise. What you end up with a system that decays to the natural security level of the WebPKI. From a threat model perspective, what you've really done is just add another CA to the system. Not better! DANE advocates tried for years to work around this problem by factoring out the DNS from DANE, and stapling DANE records to TLS handshakes. Then someone asked, "well, what happens when attackers just strip that out of the handshake". These records are used to authenticate the handshake, so you can't just set "the handshake will be secure" as an axiom. Nobody had a good answer! The DANE advocates were left saying we'd be doing something like HPKP, where browsers would remember DANE-stapled hosts after first contact. The browser vendors said "lol no". That's where things stand. The stapling thing was so bad that Geoff Huston --- a DNS/DNSSEC éminence grise --- wrote a long blog post asking (and more or less conceding) that it was time to stick a fork in the whole thing.