DoH drastically reduces the impetus for the deployment of DNSSEC; it is essentially the 2018 answer to DNSCurve/DNSCrypt. Google and the Chrome team have been pretty clear about what they think about DANE's prospects moving forward.
And, of course, you're misrepresenting Langley's blog post when you suggest that the only reason DANE isn't in Chrome is because of lookup reliability. Readers can just read the piece for themselves (it's good, and interesting!) and come to their own conclusions.
And definitely read the post by Thomas Ptacek linked to from that article: https://sockpuppet.org/blog/2015/01/15/against-dnssec/. He makes the excellent point that DNSSEC (and thus DANE) doesn't get rid of CAs at all - it just makes whoever controls the domain into a defacto CA. Yeah, Comodo behaved badly as a CA - so, the browsers are in the process of no longer trusting it; imagine if DANE were in widespread use and Verisign behaved badly - the browsers really couldn't do anything about it at all unless they wanted to stop supporting .com - which is impossible.
"Let's get rid of CAs!" Sounds great. "Let's replace the CAs with a less accountable set of companies and governments that are harder to punish for bad behavior" doesn't sound so great. But thats what DANE is.
> "Let's get rid of CAs!" Sounds great. "Let's replace the CAs with a less accountable set of companies and governments that are harder to punish for bad behavior" doesn't sound so great. But thats what DANE is.
The common counter-point is that, because nearly every CA does domain validation, the owners of the DNS keys are already capable of getting arbitrary certs. Therefore, DANE does not give DNS key owners more power; all it does is take out the CA's as a potential failure point.
And really, as long as a cert attests that "You are talking to the owner of this domain" the power over certs is always going to lie with those who control the DNS system.
A possible response is that just taking power from the CA's but leaving power with the DNS key owners is not good enough. This does make some sense. It is not entirely clear to me how we will take this power from the DNS system though. The best bet are CT-logs, which will allow after-the-fact detection of any falsely issued certs. Notably though, attribution between CA's and the DNS system isn't solved here. Perhaps if CA's store the relevant signed DNS response, we could attribute the attack to the DNS system.
Thomas Ptacek (the guy whose blog post you've linked) agrees with Thomas Ptacek (tptacek, the guy whose sub-thread you're replying to)? Not exactly a revelation.
Also Thomas has rejected the suggestion that the parts of his post that are now hopelessly wrong should be mentioned in the FAQ he prominently links. So, that post is wrong and explicitly won't be fixed, you should not rely on the "facts" in it unless you want to get laughed at.
Your mention of Comodo suggests you're badly confused. The Symantec hierarchy is in the process of being distrusted by the Mozilla and Google root programmes, not Comodo.
As to .com, it already _is_ run very badly and we already do have to put up with that because there is no way to fix it. Don't put new things in .com unless you're comfortable with for-profit companies screwing you over whenever it suits them. DNSSEC can't make that worse, it's already terrible.
That's worth emphasising - DNSSEC cannot make you more dependent on your registry operators, because you are already entirely dependent on those registry operators anyway. If the operator could be leaned on by spooks (seems plausible) that is already true today.
> Thomas Ptacek (the guy whose blog post you've linked) agrees with Thomas Ptacek (tptacek, the guy whose sub-thread you're replying to)? Not exactly a revelation.
Lol, I didn't read the username.
> So, that post is wrong and explicitly won't be fixed, you should not rely on the "facts" in it unless you want to get laughed at.
I haven't analyzed everything in that blog post. However, the case it makes against DANE I think is convincing. I linked to that blog post since it was the one that made me realized that DANE was a bad idea when I was briefly a DANE enthusiast a few years ago.
> Your mention of Comodo suggests you're badly confused.
I accidentally slipped and used the wrong CA - I think "badly confused" is a bit strong for a slip of the tounge.
> Don't put new things in .com unless you're comfortable with for-profit companies screwing you over whenever it suits them.
It sound like you are also arguing that DANE is a bad idea.
> DNSSEC can't make that worse, it's already terrible.
I don't think I said anything to the contrary.
I'm real confused by the aggressive tone - it seems like you agree with everything of substance I wrote and the things you don't agree with are things that I didn't actually say.
Actually I keep providing specifics which you ignore, for example the blog post declares that DNSSEC is "unsafe" because it can cause hostnames to be revealed and you give the example of Bank of America, owners of the bankofamerica.com domain for which you say such a policy "does not work so well".
But today actually FQDNs like 14021-nonprod.bankofamerica.com or whkgm04ye.hktskcy.apac.bankofamerica.com are not just accessible if you brute force DNS, they're automatically published, because Bank of America heavily relies, in fact, on the Web PKI and its issuers log the certificates.
It seems very strange to focus on the security for .COM when my point is that that entire TLD is badly run, it's like you're focused on how good the lock is on the front door (somebody call Deviant Ollam) at Lehman Brothers when the actual problem was they've invested all this money in worthless mortgage securities.
That's simply false. Bank of America's public servers with TLS certificates are logged (which, by the way, is also an operational security problem for them), but their other services are not.
You've picked an odd point to quibble with, since there's not only NSEC and NSEC3 but now, after the last RWC, a proposed NSEC5 to address this supposed non-problem.
And, of course, you're misrepresenting Langley's blog post when you suggest that the only reason DANE isn't in Chrome is because of lookup reliability. Readers can just read the piece for themselves (it's good, and interesting!) and come to their own conclusions.