3 ms·

I don't understand why Let's Encrypt is OK but DANE isn't. They both use DNS to authenticate certificates, why not cut out the middleman?

bawolff 4y ago
They use DNS in very different ways. I don't think they are directly comparable. Sometimes some things catch on and others don't.
NavinF 4y ago
Not much has changed since "Why not DANE in browsers (17 Jan 2015)": https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html
rakoo 4y ago
Let's encryt is a protocol, ACME, that can be implemented by any number of independent actors. Yes, it takes time, energy and money, but it is doable. And if it is possible to switch away from a bad actor, there is more incentive to not being a bad actor. DANE relies on the DNS being end-to-end secure, which all boils down to the root being secure. It's extremely centralized in a way that is just diammetrally opposed to how the Internet is designed.
tptacek 4y ago
There are a lot of reasons. The real reason DANE isn't deployed is that DNSSEC isn't deployed, and DNSSEC isn't deployed because (1) it's not an operational security win for most companies, and (2) it has an earned reputation for causing nightmare outages. That's why nothing uses DANE: because there are no DANE records to look up, and the most important (high-traffic, whatever) sites on the Internet disproportionately eschew DNSSEC. The other big reason DANE isn't deployed, even as a trial balloon in browsers for the rare cases where DANE records actually exist, is that the Internet is full of middleboxes (caches and rando routers) that block DNSSEC, or really any atypical DNS response at all. The browsers tried rolling out DANE, and it caused reliability problems. DANE advocates tried to work around this with stapled DANE records as a TLS extension, which failed due to security concerns, and is now a dead letter. (There is an obvious chicken-egg thing happening between these first two reasons that strongly suggests this will remain a stable equilibrium.) The best reason DANE isn't deployed is that it vests keying authority with organizations that can't be revoked. World governments control most of the most important TLDs, and most of those have demonstrated repeatedly that they will alter the DNS for their own policy goals. Google can dis-trust CAs that act up, and in fact they did that a few years ago for one of the largest CAs in the world. Google can't dis-trust .COM. Mozilla can realistically threaten to dis-trust any CA that doesn't implement Certificate Transparency, but nobody can threaten a TLD owner if they don't enroll in a (fictitious) DANE Transparency program --- part of the reason there is no such program.
- zinekeller 4y ago
  > The best reason DANE isn't deployed is that it vests keying authority with organizations that can't be revoked. Speaking of TLDs, there are still some TLDs that don't support DNSSEC at all, meaning that some that do want to use DNSSEC/DANE (usually for certificate pinning for MX systems) have migrated to TLDs that do. Also IIRC DANE can be used in a "verify that this is the key but also checked if it's signed by a trustworthy CA", but at this point why bother?
- candiddevmike 4y ago
  All of the problems you listed around trusting TLDs applies to Let's Encrypt/ACME DNS-01 validation though...
  - bawolff 4y ago
    I mean, with dns validation you at least have records that someone did the attack bia cert transparency, with dane the attack is harder to detect.
  - deleted 4y ago
    [deleted]
  - acdha 4y ago
    There's one useful exception: say that the Libyan government decided to override bit.ly's DNSSEC records — if all you use is DANE, they've won and they can do that seamlessly for a subset of clients without anyone else noticing. If they try the same thing attacking a DNS-validated certificate system, they lose the covert aspect because Certificate Transparency forces the malicious certificate to be logged in an immutable record. There are services which monitor those logs to alert owners and it makes it easier for researchers to piece together what happened retroactively, as we saw recently with the TrustCor affair where CT logs were useful for determining what certificates that CA had been issuing.
  - tptacek 4y ago
    No, they don't. Browsers can dis-trust LetsEncrypt; inclusion in the Mozilla and Google root programs is at their discretion.

bawolff 4y ago

They use DNS in very different ways. I don't think they are directly comparable. Sometimes some things catch on and others don't.

NavinF 4y ago

Not much has changed since "Why not DANE in browsers (17 Jan 2015)": https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html

rakoo 4y ago

Let's encryt is a protocol, ACME, that can be implemented by any number of independent actors. Yes, it takes time, energy and money, but it is doable. And if it is possible to switch away from a bad actor, there is more incentive to not being a bad actor. DANE relies on the DNS being end-to-end secure, which all boils down to the root being secure. It's extremely centralized in a way that is just diammetrally opposed to how the Internet is designed.

tptacek 4y ago

There are a lot of reasons. The real reason DANE isn't deployed is that DNSSEC isn't deployed, and DNSSEC isn't deployed because (1) it's not an operational security win for most companies, and (2) it has an earned reputation for causing nightmare outages. That's why nothing uses DANE: because there are no DANE records to look up, and the most important (high-traffic, whatever) sites on the Internet disproportionately eschew DNSSEC. The other big reason DANE isn't deployed, even as a trial balloon in browsers for the rare cases where DANE records actually exist, is that the Internet is full of middleboxes (caches and rando routers) that block DNSSEC, or really any atypical DNS response at all. The browsers tried rolling out DANE, and it caused reliability problems. DANE advocates tried to work around this with stapled DANE records as a TLS extension, which failed due to security concerns, and is now a dead letter. (There is an obvious chicken-egg thing happening between these first two reasons that strongly suggests this will remain a stable equilibrium.) The best reason DANE isn't deployed is that it vests keying authority with organizations that can't be revoked. World governments control most of the most important TLDs, and most of those have demonstrated repeatedly that they will alter the DNS for their own policy goals. Google can dis-trust CAs that act up, and in fact they did that a few years ago for one of the largest CAs in the world. Google can't dis-trust .COM. Mozilla can realistically threaten to dis-trust any CA that doesn't implement Certificate Transparency, but nobody can threaten a TLD owner if they don't enroll in a (fictitious) DANE Transparency program --- part of the reason there is no such program.

zinekeller 4y ago
> The best reason DANE isn't deployed is that it vests keying authority with organizations that can't be revoked. Speaking of TLDs, there are still some TLDs that don't support DNSSEC at all, meaning that some that do want to use DNSSEC/DANE (usually for certificate pinning for MX systems) have migrated to TLDs that do. Also IIRC DANE can be used in a "verify that this is the key but also checked if it's signed by a trustworthy CA", but at this point why bother?
candiddevmike 4y ago
All of the problems you listed around trusting TLDs applies to Let's Encrypt/ACME DNS-01 validation though...
- bawolff 4y ago
  I mean, with dns validation you at least have records that someone did the attack bia cert transparency, with dane the attack is harder to detect.
- deleted 4y ago
  [deleted]
- acdha 4y ago
  There's one useful exception: say that the Libyan government decided to override bit.ly's DNSSEC records — if all you use is DANE, they've won and they can do that seamlessly for a subset of clients without anyone else noticing. If they try the same thing attacking a DNS-validated certificate system, they lose the covert aspect because Certificate Transparency forces the malicious certificate to be logged in an immutable record. There are services which monitor those logs to alert owners and it makes it easier for researchers to piece together what happened retroactively, as we saw recently with the TrustCor affair where CT logs were useful for determining what certificates that CA had been issuing.
- tptacek 4y ago
  No, they don't. Browsers can dis-trust LetsEncrypt; inclusion in the Mozilla and Google root programs is at their discretion.