5 ms·

Can we have [2015] in the title? Also, this ignores the main argument against DNSSEC / DANE: > With DANE, you only have to trust ICANN, the country your TLD r

by theamk 5y ago

Can we have [2015] in the title? Also, this ignores the main argument against DNSSEC / DANE: > With DANE, you only have to trust ICANN, the country your TLD resides in, and your DNS service provider. This is far from ideal, but the traditional CA system requires trusting all of those entities and over 600 others. Those 600 CAs are accountable to browsers -- the bad certificates are detected, and companies which misbehave are kicked out (see StartCom [0] for example). With DANE, there is no such mechanism. Your TLD provider leaked the key and is denying it? Nothing you (or anyone) can do without losing your domain name. The crypto has been broken and needs upgrades (see SHA-1), but provider does not want to do this? No way to force this. In the field of cybersecurity, I trust a combination of Mozilla/Apple/Google more than any government agency. [0] https://en.wikipedia.org/wiki/StartCom https://en.wikipedia.org/wiki/StartCom

Eikon 5y ago
The CA system for TLS certificates is really dumb. Why can't we just upload a certificate chain as a TXT field in some DNS entry? Anyway, without HSTS, if your resolver is lying you are in bad waters and most (all?) CAs allow validation through dns records already. I'd much much prefer that as it would not be more insecure than "trusting" hundreds of third parties but would bypass a ton of useless organisations.
- tptacek 5y ago
  The obvious problem with storing certificate chains in TXT records is that it deeds control over your site cryptography to the government that controls your TLD, and, likely, to the "Five Eyes" IC consortium that probably exerts de facto control over the DNS roots themselves. We don't have to wonder whether governments manipulate the DNS for policy reasons; they do so loudly and proudly. People assume governments can simply suborn CAs directly, but that leads us to our next issue: A slightly less obvious problem with storing certificate chains in the DNS is that you can't revoke the DNS. You can, in fact, revoke entire chunks of the WebPKI. Not only have Chrome and Mozilla done so before, they did it to the largest and most famous CA. Google cannot revoke .COM; in fact, in practical terms, they can't even leave .COM, because hundreds of millions of users are trained to reach them at .COM. An even less obvious problem with storing certificate chains in the DNS is that virtually no software --- especially not the low-level library code that everything is built on --- is designed to assume that the DNS can fail for policy reasons. When certificates are for whatever reason rejected, you get a UI flow telling you what's going on. It doesn't do a very good job, but it's better than nothing, which is what you get with DNSSEC: your site silently falling off the Internet, as if it had never existed. There are other reasons too, but these are some of the high-level ones.
- theamk 5y ago
  This depends on your threat model. Here is mine, in order of importance: 1. Compromised local network (such as bad public wifi, tampering by ISP) 2. Compromised registrar (DNS or CA) 3. Compromised backbone internet (possibly because of state-level interference) 4. Compromised infrastructure of the website I am visiting ("4" is all the way at the end of the list because if the website is compromised, they likely can get access to DB/web server directly, and DNS/TLS things don't really matter) So even without HSTS, you are protected against 1 and 3; and, thanks to Certificate Transparency, have a good way to detect 2 (because Let's Encrypt does DNS queries from multiple regions and writes all certificates to CT Log). This is all live and works right now. And the threat of browser removal really causes CA to pay attention to browser security. Compared to this, the DNSSEC solves 1 (at least so I've heard, the original spec was vulnerable); does not solve 2 and removes all the pressure for registrars to improve; and just gives up on 3 when the state is involved. Additionally, your "upload a certificate chain" approach sounds like you want to skip using CT, which means that detection of 2 and 3 is also gone. In the past there were more reasons to use DNSSEC. But now, when Let's Encrypt exists, and the state-endorsed internet interference happens in multiple countries, it simply makes no sense.
  - tptacek 5y ago
    DNSSEC absolutely does not solve #1. Between you and your local resolver, DNSSEC collapses down to a single header bit, and while we have made large strides in signature cryptography, we have not yet secured single-bit signatures. Your ISP can trick you simply by flipping the "authenticated data" bit off or on in DNS headers. Problem #1 is why DoH exists. DoH does a good job at dealing with untrusted local DNS! In fact: it addresses most of the real on-the-wire threats to DNS, full stop. But it has nothing to do with DNSSEC.
- toast0 5y ago
  I agree that CAs are pretty dumb, but the certificate transparency logs are pretty nice to have. If a certificate must be logged to be used and if the logs are publicly accessible, I have a chance of noticing if someone got a certificate issued for my domain (either by tricking a CA, a nefarious CA, or by compromising DNS). I don't think I have a chance of noticing if certificates are just TXT records and someone can compromise DNS (especially if it's selective). Maybe if you also require DANE certificates to have certificate transparency records, but automation of ACME is probably simpler than automation of DNS changes.
deleted 5y ago
[deleted]
remram 5y ago
We need certificate transparency logs for DNSSEC (for ICANN and TLDs at least).
- tptacek 5y ago
  Two big problems with CT for DNSSEC: 1. It doesn't exist right now. 2. Getting CT working for the WebPKI was a lot of work, done in tandem by a lot of very talented people, and because virtually nobody in the industry uses DNSSEC (go look!), there's no incentive for that work to happen. There's no question that the IETF could get a working group together to specify a transparency log for DNSSEC... eventually. I'd happily start a pool to bet on how long it would take them to bikeshed it out. But actually getting it deployed to the level of effectiveness that CT has today is a totally different story. It has been over twenty years of work just getting DNSSEC to the (very bad) place it's at today. We should factor that in when we talk about what DNSSEC can and can't do. A think DNSSEC can't do today: provide transparency logs, like the WebPKI does.
  - Operyl 5y ago
    Not arguing either which way, but was curious and did a few names off the top of my head: yes: Cloudflare no: easyDNS, Google, Apple, Facebook, Wikipedia/media, Twitter, Reddit I knew DNSSEC wasn't well-deployed, but I didn't realize how little.
    - tptacek 5y ago
      Keep going! It gets funnier as you keep looking. (For those playing the home game, it's just `host -t ds <domain>` to check for DNSSEC; `host -t ds salesforce.com` is what it looks like when you do have DNSSEC enabled.) To save some trouble: other companies that haven't enabled DNSSEC include Mozilla, Netflix, Stripe, Bank of America, Citigroup, Microsoft, Adobe, Oracle, Amazon, Intel, IBM, Atlassian, Coinbase, Equinix, Datadog, Twilio, Ebay, and Shopify. Speaking of Salesforce: the chatter is that the real reason Slack enabled DNSSEC briefly is because Salesforce --- their parent company --- already had it enabled, presumably for the same bogus FedRAMP reason. Cloudflare is probably the most notable DNSSEC user. But then: Cloudflare sells DNSSEC services.
cryptonector 5y ago
> Also, this ignores the main argument against DNSSEC / DANE: Incorrect. You can sign your own root zone anytime you like, and we could see alt-roots if the root misbehaves.
- tptacek 5y ago
  DNSSEC: it's secure as long as you don't trust the DNS hierarchy.
  - cryptonector 5y ago
    Fallacious argument. With WebPKI there are many roots that can MITM you. With DNSSEC there is only one. Once we have CT for DNSSEC it will be easier to watch that root and the CA for each label in the domainname on the way to the QName than it is to watch tens of CAs in WebPKI.
    - tptacek 5y ago
      Did you accidentally respond to the wrong thread? I do that all the time. The thread you're commenting on is one where the previous commenter suggested that you could mitigate DNSSEC's reliance on a government controlled PKI by substituting your own DNS roots.

by theamk 5y ago

Eikon 5y ago

The CA system for TLS certificates is really dumb. Why can't we just upload a certificate chain as a TXT field in some DNS entry? Anyway, without HSTS, if your resolver is lying you are in bad waters and most (all?) CAs allow validation through dns records already. I'd much much prefer that as it would not be more insecure than "trusting" hundreds of third parties but would bypass a ton of useless organisations.

tptacek 5y ago
The obvious problem with storing certificate chains in TXT records is that it deeds control over your site cryptography to the government that controls your TLD, and, likely, to the "Five Eyes" IC consortium that probably exerts de facto control over the DNS roots themselves. We don't have to wonder whether governments manipulate the DNS for policy reasons; they do so loudly and proudly. People assume governments can simply suborn CAs directly, but that leads us to our next issue: A slightly less obvious problem with storing certificate chains in the DNS is that you can't revoke the DNS. You can, in fact, revoke entire chunks of the WebPKI. Not only have Chrome and Mozilla done so before, they did it to the largest and most famous CA. Google cannot revoke .COM; in fact, in practical terms, they can't even leave .COM, because hundreds of millions of users are trained to reach them at .COM. An even less obvious problem with storing certificate chains in the DNS is that virtually no software --- especially not the low-level library code that everything is built on --- is designed to assume that the DNS can fail for policy reasons. When certificates are for whatever reason rejected, you get a UI flow telling you what's going on. It doesn't do a very good job, but it's better than nothing, which is what you get with DNSSEC: your site silently falling off the Internet, as if it had never existed. There are other reasons too, but these are some of the high-level ones.
theamk 5y ago
This depends on your threat model. Here is mine, in order of importance: 1. Compromised local network (such as bad public wifi, tampering by ISP) 2. Compromised registrar (DNS or CA) 3. Compromised backbone internet (possibly because of state-level interference) 4. Compromised infrastructure of the website I am visiting ("4" is all the way at the end of the list because if the website is compromised, they likely can get access to DB/web server directly, and DNS/TLS things don't really matter) So even without HSTS, you are protected against 1 and 3; and, thanks to Certificate Transparency, have a good way to detect 2 (because Let's Encrypt does DNS queries from multiple regions and writes all certificates to CT Log). This is all live and works right now. And the threat of browser removal really causes CA to pay attention to browser security. Compared to this, the DNSSEC solves 1 (at least so I've heard, the original spec was vulnerable); does not solve 2 and removes all the pressure for registrars to improve; and just gives up on 3 when the state is involved. Additionally, your "upload a certificate chain" approach sounds like you want to skip using CT, which means that detection of 2 and 3 is also gone. In the past there were more reasons to use DNSSEC. But now, when Let's Encrypt exists, and the state-endorsed internet interference happens in multiple countries, it simply makes no sense.
- tptacek 5y ago
  DNSSEC absolutely does not solve #1. Between you and your local resolver, DNSSEC collapses down to a single header bit, and while we have made large strides in signature cryptography, we have not yet secured single-bit signatures. Your ISP can trick you simply by flipping the "authenticated data" bit off or on in DNS headers. Problem #1 is why DoH exists. DoH does a good job at dealing with untrusted local DNS! In fact: it addresses most of the real on-the-wire threats to DNS, full stop. But it has nothing to do with DNSSEC.
toast0 5y ago
I agree that CAs are pretty dumb, but the certificate transparency logs are pretty nice to have. If a certificate must be logged to be used and if the logs are publicly accessible, I have a chance of noticing if someone got a certificate issued for my domain (either by tricking a CA, a nefarious CA, or by compromising DNS). I don't think I have a chance of noticing if certificates are just TXT records and someone can compromise DNS (especially if it's selective). Maybe if you also require DANE certificates to have certificate transparency records, but automation of ACME is probably simpler than automation of DNS changes.

deleted 5y ago

[deleted]

remram 5y ago

We need certificate transparency logs for DNSSEC (for ICANN and TLDs at least).

tptacek 5y ago
Two big problems with CT for DNSSEC: 1. It doesn't exist right now. 2. Getting CT working for the WebPKI was a lot of work, done in tandem by a lot of very talented people, and because virtually nobody in the industry uses DNSSEC (go look!), there's no incentive for that work to happen. There's no question that the IETF could get a working group together to specify a transparency log for DNSSEC... eventually. I'd happily start a pool to bet on how long it would take them to bikeshed it out. But actually getting it deployed to the level of effectiveness that CT has today is a totally different story. It has been over twenty years of work just getting DNSSEC to the (very bad) place it's at today. We should factor that in when we talk about what DNSSEC can and can't do. A think DNSSEC can't do today: provide transparency logs, like the WebPKI does.
- Operyl 5y ago
  Not arguing either which way, but was curious and did a few names off the top of my head: yes: Cloudflare no: easyDNS, Google, Apple, Facebook, Wikipedia/media, Twitter, Reddit I knew DNSSEC wasn't well-deployed, but I didn't realize how little.
  - tptacek 5y ago
    Keep going! It gets funnier as you keep looking. (For those playing the home game, it's just `host -t ds <domain>` to check for DNSSEC; `host -t ds salesforce.com` is what it looks like when you do have DNSSEC enabled.) To save some trouble: other companies that haven't enabled DNSSEC include Mozilla, Netflix, Stripe, Bank of America, Citigroup, Microsoft, Adobe, Oracle, Amazon, Intel, IBM, Atlassian, Coinbase, Equinix, Datadog, Twilio, Ebay, and Shopify. Speaking of Salesforce: the chatter is that the real reason Slack enabled DNSSEC briefly is because Salesforce --- their parent company --- already had it enabled, presumably for the same bogus FedRAMP reason. Cloudflare is probably the most notable DNSSEC user. But then: Cloudflare sells DNSSEC services.

cryptonector 5y ago

> Also, this ignores the main argument against DNSSEC / DANE: Incorrect. You can sign your own root zone anytime you like, and we could see alt-roots if the root misbehaves.

tptacek 5y ago
DNSSEC: it's secure as long as you don't trust the DNS hierarchy.
- cryptonector 5y ago
  Fallacious argument. With WebPKI there are many roots that can MITM you. With DNSSEC there is only one. Once we have CT for DNSSEC it will be easier to watch that root and the CA for each label in the domainname on the way to the QName than it is to watch tens of CAs in WebPKI.
  - tptacek 5y ago
    Did you accidentally respond to the wrong thread? I do that all the time. The thread you're commenting on is one where the previous commenter suggested that you could mitigate DNSSEC's reliance on a government controlled PKI by substituting your own DNS roots.