Do the words "no discernible reason" just mean something very different to you than they do to me? Because I've written somewhere in the vicinity of 100,000 words about the problems of DNSSEC over the last 20 years. My written DNSSEC critique predates HN itself.
This particular issue has nothing to do with "aligning authentication with the name hierarchy". The exact same thing that happened to EMudhra could happen to any TLD operator. The difference is that we have essentially no recourse when that happens, and far less ability to detect malfeasance.
Low TTLs aren’t incompatible with the ideal of using DNSSEC though? From what I can tell DS records typically have TTL of 1 day in the root domain.
What is a difference, versus DANE, is that TLS uses CT. Compromised TLDs happened recently but was found out through CT. A compromised TLD still kills the whole system for a time regardless.
I think DNSSEC still has some use in enforcing email TLS and for CAs.
I meant that for a compromised TLD key, the DS record at root lasts for a day. So I didn’t follow how the compromise in a theoretical DANE-only world would be inherently long-lasting.
You said “no recourse,” which I took to mean no recourse even if known. I don’t follow that. The key/DS record at root can be changed. There may not be a “TLD death penalty,” but the key could be changed.
Now without CT it may be tougher to know about the compromise. For websites that don’t have the luxury of certificate pinning, a compromise of TLD kills the whole thing, at least for a time.
None of my arguments are that a compromised DNSSEC key would be inherently long-lasting?
The "recourse" issue is that after you resolve a DNSSEC misissuance, you cannot then murder the TLD operator that did that to you. But that's exactly what's about to happen with EMudhra.
Again, I don’t get this argument. A compromised TLD absolutely kills any validation (other than EV) already. An A/AAAA can be posted for page validation or TXT for DNS validation.
As far as I know, no TLD operator has gotten the death penalty. It is technically possible for root to change the IP addresses, but it would be bound up in whatever the governance is of the domains.
But the downside isn’t something new that would just apply to a DANE world. That downside still exists in the CA world. The CA is just an additional point of failure, along with the TLD.
I don’t think you’re grokking what “death penalty” means here.
If a CA does something stupid or malicious, the browsers remove that CA from their root stores, effectively ending that CA’s existence as a going concern. People with websites go buy replacement certs from a new vendor and life goes on. This has happened before and is a massive incentive for CAs to not fuck around, and it incentivizes everybody to lean into improving the security of issuance.
It’s basically impossible to do the same thing to a TLD. If .io goofs around and is negligent in handling their security, you can’t do anything unless you’re willing to make every .io website rehome to a new TLD.
CT is a red herring. There is no reason something like that couldn't be used for DANE as well if you wanted and Web PKI didn't have any CT either until recently. It's a non-argument - at best it betrays that this is all about giving root stores the power to unilaterally demand compliance with the policies they want.
It would need to be through TLDs all reporting new DANE records, or DANE itself would need to change.
The threat model here is the TLD was somehow unknowingly hacked and the bad DNS records are somehow not noticed. Or worse, the body governing TLD is in on it. In these cases, only the users of the websites are in a position to report on the bad certs. Each website could try to monitor the DNS records similar to CT logs, though for targeted attacks that may not work.
DNSSEC creates more operational issues than it solves. It's easy to screw up, which means your domain completely stops resolving when that inevitably occurs. None of the FAANGs use it for their main web sites, so what does that tell you?
It can also be disabled at the whim of anyone operating a resolver, as was seen with Cloudflare during the .de TLD DNSSEC snafu back in May.
Do the words "no discernible reason" just mean something very different to you than they do to me? Because I've written somewhere in the vicinity of 100,000 words about the problems of DNSSEC over the last 20 years. My written DNSSEC critique predates HN itself.
This particular issue has nothing to do with "aligning authentication with the name hierarchy". The exact same thing that happened to EMudhra could happen to any TLD operator. The difference is that we have essentially no recourse when that happens, and far less ability to detect malfeasance.
Low TTLs aren’t incompatible with the ideal of using DNSSEC though? From what I can tell DS records typically have TTL of 1 day in the root domain.
What is a difference, versus DANE, is that TLS uses CT. Compromised TLDs happened recently but was found out through CT. A compromised TLD still kills the whole system for a time regardless.
I think DNSSEC still has some use in enforcing email TLS and for CAs.
Sorry, I'm a little confused as to how TTLs are at issue here? I don't think TTLs are a reason DNSSEC is problematic.
I meant that for a compromised TLD key, the DS record at root lasts for a day. So I didn’t follow how the compromise in a theoretical DANE-only world would be inherently long-lasting.
You said “no recourse,” which I took to mean no recourse even if known. I don’t follow that. The key/DS record at root can be changed. There may not be a “TLD death penalty,” but the key could be changed.
Now without CT it may be tougher to know about the compromise. For websites that don’t have the luxury of certificate pinning, a compromise of TLD kills the whole thing, at least for a time.
None of my arguments are that a compromised DNSSEC key would be inherently long-lasting?
The "recourse" issue is that after you resolve a DNSSEC misissuance, you cannot then murder the TLD operator that did that to you. But that's exactly what's about to happen with EMudhra.
Again, I don’t get this argument. A compromised TLD absolutely kills any validation (other than EV) already. An A/AAAA can be posted for page validation or TXT for DNS validation.
As far as I know, no TLD operator has gotten the death penalty. It is technically possible for root to change the IP addresses, but it would be bound up in whatever the governance is of the domains.
But the downside isn’t something new that would just apply to a DANE world. That downside still exists in the CA world. The CA is just an additional point of failure, along with the TLD.
What is added by the CA world is CT.
I don’t think you’re grokking what “death penalty” means here.
If a CA does something stupid or malicious, the browsers remove that CA from their root stores, effectively ending that CA’s existence as a going concern. People with websites go buy replacement certs from a new vendor and life goes on. This has happened before and is a massive incentive for CAs to not fuck around, and it incentivizes everybody to lean into improving the security of issuance.
It’s basically impossible to do the same thing to a TLD. If .io goofs around and is negligent in handling their security, you can’t do anything unless you’re willing to make every .io website rehome to a new TLD.
Root store operators being legislators, judge, jury and executioners is not a good thing.
Far better for unaccountable TLD operators to have unrebuttable plenary authority over all our cryptography keys. What could go wrong?
CT is a red herring. There is no reason something like that couldn't be used for DANE as well if you wanted and Web PKI didn't have any CT either until recently. It's a non-argument - at best it betrays that this is all about giving root stores the power to unilaterally demand compliance with the policies they want.
It would need to be through TLDs all reporting new DANE records, or DANE itself would need to change.
The threat model here is the TLD was somehow unknowingly hacked and the bad DNS records are somehow not noticed. Or worse, the body governing TLD is in on it. In these cases, only the users of the websites are in a position to report on the bad certs. Each website could try to monitor the DNS records similar to CT logs, though for targeted attacks that may not work.
DNSSEC creates more operational issues than it solves. It's easy to screw up, which means your domain completely stops resolving when that inevitably occurs. None of the FAANGs use it for their main web sites, so what does that tell you?
It can also be disabled at the whim of anyone operating a resolver, as was seen with Cloudflare during the .de TLD DNSSEC snafu back in May.