3 ms·

Now that Let's Encrypt and ZeroSSL give (almost) anyone certs if they can add a DNS record or serve a file over HTTP on a domain, your argument against DNSSEC o

by easrng 5y ago

Now that Let's Encrypt and ZeroSSL give (almost) anyone certs if they can add a DNS record or serve a file over HTTP on a domain, your argument against DNSSEC on the grounds of increased government/registry control doesn't really make sense. Given that you can get a cert by controlling DNS now anyway, why not use DNSSEC and DANE rather than just trusting that Let's Encrypt's routes to DNS servers are trustworthy?

tptacek 5y ago
Mis-issued certificates are (1) highly visible, (2) revocable, and (3) inherently time-limited. Governments have permanent, de jure control over the DNS hierarchy. My snarky reply to this is usually just "OK, go exploit DNS to get a GMail certificate issued. It's just DNS, you should have no problem."
- tialaramex 5y ago
  One of my previous employers was interested in this problem (I'm pretty sure the list of my previous employers is a matter of public record if you're curious enough) and assigned me to look at the actual facts using raw DNS data from the network. It was clear that somebody (presumably nation state actors, although likely not via the DNS hierarchy itself) tampers with DNS, in particular for military or "civil order" type authorities in certain countries. However, they don't usually bother using this to obtain a Web PKI certificate even though they easily could. Can you guess why? What they want is credentials. So, hijack DNS answers for the mail server, user likely connects without TLS (or in a "fail open" setup supported by many mail clients so that TLS was abandoned once it didn't work) and you get their credentials - they don't even need to do anything, their mail client probably passively does this every few minutes while they sleep. But even for the web a lot of lay users don't type https://server.name.example/ https://server.name.example/ to reach the site, they just type server.name.example and the redirect secures it... until one day it doesn't. You'd notice. I'd notice. 99% of users would not notice, especially before browsers all added affirmative warnings in the last few years.
theamk 5y ago
Both Let's Encrypt and ZeroSSL participate in Certificate Transparency, so you at least have the detection of unusual certificates. Let me turn around your question: Now that Let's Encrypt and ZeroSSL give (almost) anyone certs, why should we bother implementing all new system with less features and less accountability?
- kazen44 5y ago
  Because DNSSEC is not just used for web stuff, in comparison to TLS certificates?
  - theamk 5y ago
    TLS certificates are not just used for web stuff either, many protocols use TLS. For example in IoT world, MQTT over TLS is common. One non-TLS-based protocol I can think of is SSH, and I agree that SSHFP does sound useful. But given the limited use case of this, SSH's native certificate support, and how easy it is to pre-fill the known_hosts file, I don't think this feature is worth implementing DNSSEC.
    - easrng 5y ago
      There's also DKIM.
      - tptacek 5y ago
        ... which has widespread deployment without DNSSEC.
- easrng 5y ago
  It doesn't seem like there's any reason DANE is incompatible with Certificate Transparency. Support could potentially even be integrated with public revolvers to automatically submit certs to a CT log when a TLSA record is looked up[1]. You can use both DANE and a CA-issued certificate at the same time if you want. With Let's Encrypt and the CA system, you have to trust Let's Encrypt, the DNS servers[2] Let's Encrypt uses, every router between Let's Encrypt and the DNS servers[2], and in most setups every other CA Mozilla/Google/your OS vendor ships too. With DANE, you need to trust the people with the keys for the DNS servers[2] still, but you don't have the MITM risk, assuming local validation which is the only thing that makes sense with modern computers. What features are possible with the CA system but not DANE? [1]: This would require making a TLS connection to the server since only the hash is in the TLSA record which isn't ideal, but it would be possible. [2]: I'm talking about the DNS servers needed for recursive resolution, so the root servers, the domain's TLD's namesevers, and the authoritative nameserver for the domain.

by easrng 5y ago

tptacek 5y ago

Mis-issued certificates are (1) highly visible, (2) revocable, and (3) inherently time-limited. Governments have permanent, de jure control over the DNS hierarchy. My snarky reply to this is usually just "OK, go exploit DNS to get a GMail certificate issued. It's just DNS, you should have no problem."

tialaramex 5y ago
One of my previous employers was interested in this problem (I'm pretty sure the list of my previous employers is a matter of public record if you're curious enough) and assigned me to look at the actual facts using raw DNS data from the network. It was clear that somebody (presumably nation state actors, although likely not via the DNS hierarchy itself) tampers with DNS, in particular for military or "civil order" type authorities in certain countries. However, they don't usually bother using this to obtain a Web PKI certificate even though they easily could. Can you guess why? What they want is credentials. So, hijack DNS answers for the mail server, user likely connects without TLS (or in a "fail open" setup supported by many mail clients so that TLS was abandoned once it didn't work) and you get their credentials - they don't even need to do anything, their mail client probably passively does this every few minutes while they sleep. But even for the web a lot of lay users don't type https://server.name.example/ https://server.name.example/ to reach the site, they just type server.name.example and the redirect secures it... until one day it doesn't. You'd notice. I'd notice. 99% of users would not notice, especially before browsers all added affirmative warnings in the last few years.

theamk 5y ago

Both Let's Encrypt and ZeroSSL participate in Certificate Transparency, so you at least have the detection of unusual certificates. Let me turn around your question: Now that Let's Encrypt and ZeroSSL give (almost) anyone certs, why should we bother implementing all new system with less features and less accountability?

kazen44 5y ago
Because DNSSEC is not just used for web stuff, in comparison to TLS certificates?
- theamk 5y ago
  TLS certificates are not just used for web stuff either, many protocols use TLS. For example in IoT world, MQTT over TLS is common. One non-TLS-based protocol I can think of is SSH, and I agree that SSHFP does sound useful. But given the limited use case of this, SSH's native certificate support, and how easy it is to pre-fill the known_hosts file, I don't think this feature is worth implementing DNSSEC.
  - easrng 5y ago
    There's also DKIM.
    - tptacek 5y ago
      ... which has widespread deployment without DNSSEC.
easrng 5y ago
It doesn't seem like there's any reason DANE is incompatible with Certificate Transparency. Support could potentially even be integrated with public revolvers to automatically submit certs to a CT log when a TLSA record is looked up[1]. You can use both DANE and a CA-issued certificate at the same time if you want. With Let's Encrypt and the CA system, you have to trust Let's Encrypt, the DNS servers[2] Let's Encrypt uses, every router between Let's Encrypt and the DNS servers[2], and in most setups every other CA Mozilla/Google/your OS vendor ships too. With DANE, you need to trust the people with the keys for the DNS servers[2] still, but you don't have the MITM risk, assuming local validation which is the only thing that makes sense with modern computers. What features are possible with the CA system but not DANE? [1]: This would require making a TLS connection to the server since only the hash is in the TLSA record which isn't ideal, but it would be possible. [2]: I'm talking about the DNS servers needed for recursive resolution, so the root servers, the domain's TLD's namesevers, and the authoritative nameserver for the domain.