[temac]

> that's one of the (inadequate) methods that the CA/BF permits for verification at issuance

Why inadequate (in the absolute)? This can be automated and let's encrypt allows verification through DNS, moreover this allows verification for wildcard certificates.

Now in this particular case maybe they should have gone through HTTP, and even automated with ACME. But there is nothing inadequate in the absolute in DNS verification. Besides allowing wildcard it also allows verification when you don't control the web server(s), when you don't even have a webserver at all, when the standard ports are occupied for something else, etc.

[Hizonner]

> Why inadequate (in the absolute)?

The point of X.509 certificates is that you can't rely on information you get either from the DNS or from the HTTP server. If you could, you wouldn't need the whole mess in the first place.

Sure, the verification helps, because you have to successfully fool both the client and the CA. But if you can fool one, there's a strong chance that you can fool the other. In the end, the CA is still relying on exactly the same information that the client isn't supposed to have to rely on.

The original idea behind X.509 was that verification would be "out of band", but that turned out to be expensive and non-scalable, so the X.509 world, including the CA/BF, resorted to this very weak kind of verification. They try to backstop it with stuff like certificate transparency, but it's just adding epicycles that aren't particularly reassuring.

If everybody used DNSSEC, then DNS-based verification would be OK. But at that point you ought to just distribute key hashes through the DNS and dispense with X.509 entirely. That's actually what should have happened, and probably what would have happened if X.509 hadn't still been such a cash cow at the times when the various standards solidified beyond all chance of improvement. Because of that "cash cow" status, there was a lot of obvious sabotage aimed at entrenching X.509 and fighting any attempt to improve the situation. And now we're stuck with it.

[schoen]

The Chrome team was pretty averse to implementing DANE as an alternative to the web PKI. I don't think I understood why, but their reluctance seemed to be what stopped its momentum (maybe outside of SMTP?).

[tptacek]

'agl wrote a blog post about it. There were two big problems, one in principle and one practical.

The practical: you can't reliably run DNSSEC everywhere Chrome runs. Networks get really fucky with any even slightly unusual DNS messages.

The principle: because you can't realistically ever declare a "flag day" and deprecate the X.509 WebPKI, you have to support both systems, so DANE doesn't collapse your trust anchors down to a smaller set; it actually adds to the number of things you have to trust.

[schoen]

These are strong arguments.

It's really tragic that the Internet is so ossified. (Not just in this regard, but in many others.)

[Hizonner]

I'm more thinking about the pre-Chrome era. The DANE drafts weren't even written, let alone standardized, until it was already hard to move and really hard to get people to move. That slowness had a whole lot to do with obstructionism, FUD, and influence campaigning, from commercial interests, specifically Verisign, and perhaps from some anti-cryptography "national security" interests as well.

Admittedly DNSSEC is an essential prerequisite and wasn't really baked, but it was being delayed by essentially the same FUD. And DNSSEC got quite usable, from a pure technology readiness point of view, pretty fast once people started putting a little urgency behind it later on. It's still relatively hard to use, but that would evaporate in six months if there were some impetus for it to get more users.

Not that the browsers helped, mind you (Mozilla wasn't really any better). A switch to DNS as root of trust still could have been done when DANE was finished if there'd been any real will. Much less will than it takes to establish this or that bad-idea standard that's of no value to anybody but advertisers. Or for that matter to set up weird, mutant, off-the-wall, who-asked-for-that, solving-the-wrong-problem-in-the-wrong-way hackery like DNS over HTTP.

Still, by that time, the browsers could point not only at an entrenched system of practice, but also at a ton of broken, clearly-non-standards-compliant middleboxes on the network screwing up DNS, especially in "The Enterprise(TM)". Personally, I had, and still have, zero sympathy for the people who put those boxes there or put themselves behind them. I would have given them exactly zero consideration. But a lot of people somehow seem to think that one system's bad behavior obliges everybody else to bend over backwards to accommodate that system forever after.

There is actually one legitimate knock against DNSSEC: it makes replies bigger, which makes DNS a worse DoS amplifier. I think it's worth it, and if it weren't my reponse would probably have just been to start moving DNS over TCP. But at least there's a somewhat respectable argument there. Strangely, it was never the main argument you heard.

[tptacek]

Ironically, DOS amplification is the one argument against DNSSEC I don't buy; you can already use DNS quite effectively as an amplifier, along with other protocols.

The fundamental problem with this whole line of argument though is that, even if things worked well (they did not; ask Slack) you're still just trading the WebPKI --- with all its warts --- for a system that is even less transparent, and that is de jure operated by world governments. There will, for instance, never be a "DANE Transparency" log; not only because DANE will never be deployed for real, but also because the market forces that coerced CAs into adopting CT don't exist in the DNS.