6 ms·

The worst part is actually that very few of the TLD support dnssec, so it still is a chinken-and-egg problem (and the available tooling remains atrocius). But

The worst part is actually that very few of the TLD support dnssec, so it still is a chinken-and-egg problem (and the available tooling remains atrocius). But what alternative is there for securing the dns chain? DNS-over-HTTP requires time sync, the usual CA problems and it only works for the resolver to the client, it's not used for authoritative servers. DNSCrypt? Sounds good, but the server key is published in the NS record, which gets published in the old cleartext DNS. So we are still not securing the authoritative part. Unfortunately DNSSEC is still the only option to secure the whole DNS chain.

jedisct1 3y ago
> DNSCrypt? Sounds good, but the server key is published in the NS record, which gets published in the old cleartext DNS What is published in DNS records are the public certificates, not their signatures.
- Luker88 3y ago
  yes, but that was my point. You publish on an unsecure channel(DNS) the public key. Then, after the resolver gets the key, everything is safe. But getting the key might not be safe at all. DNSCrypt has been out a couple of years but does not yet have a standard RFC and is not used by the dns root servers. Or did I miss something in the chain of trust?
  - jedisct1 3y ago
    > DNSCrypt has been out a couple of years but does not yet have a standard RFC https://datatracker.ietf.org/doc/draft-denis-dprive-dnscrypt/ https://datatracker.ietf.org/doc/draft-denis-dprive-dnscrypt... It's not used by DNS root servers because it's designed to secure communications between clients and caches, not between caches and authoritative servers.
hannob 3y ago
> But what alternative is there for securing the dns chain? You're asking the wrong question. The better question would be: What do I want to achieve by securing the DNS chain, and can I do that in a different way? What you ultimately want is to make sure you're communicating with the correct other party. And the way to achieve this is TLS with certificates, validated via the WebPKI. I'm not saying TLS+WebPKI is perfect. But it works certainly a lot better than DNSSEC (which, let's be honest, does not work in practice).
- cyberax 3y ago
  > What do I want to achieve by securing the DNS chain, and can I do that in a different way? Ability to ditch the CA infrastructure with DANE.
  - hannob 3y ago
    Yeah, ok, but then you need to ask if DANE achieves that. And the answer to that is clearly "no". DANE never made it past an experimental browser plugin, and as far as I know that isn't even developed any more. In the time where DANE achieved nothing, we got Let's Encrypt, we got CT, and a whole bunch of other improvements to the WebPKI.
    - cyberax 3y ago
      DANE technically achieved that, I played around with OpenSSL plugin for DANE back in 2010 (when the . was signed). But yeah, I get your point. Right now, the path ahead is stapled DANE TLS extension. Basically, the idea is that you can use simple unauthenticated DNS to get the domain name, just like now. Then you get the complete DNSSEC-authenticated DNS chain for the DANE record as a part of the TLS handshake: https://datatracker.ietf.org/doc/rfc9102/ https://datatracker.ietf.org/doc/rfc9102/ This seems to be the best of both worlds: 1. We keep DNS as a simple and nimble UDP-based service, without trying to cram the signature in each packet. 2. Since we HAVE to use TLS anyway to achieve any meaningful security, we can just transmit the full DNS chain (up to the root zone!) with signatures easily as a part of the TLS handshake. 3. The client then just needs to validate this chain, and it only needs to have the root zone's key as the root of trust. 4. The root zone's key changes fairly infrequently (once in a decade), so IoT devices can use it to bootstrap themselves.
      - AndyMcConachie 3y ago
        > 4. The root zone's key changes fairly infrequently (once in a decade), so IoT devices can use it to bootstrap themselves. This is not true, nor will it be true into the future.
cyberax 3y ago
> The worst part is actually that very few of the TLD support dnssec ??? All the "regular" TLDs support DNSSEC: .com, .net, .org, co.uk
- chkal 3y ago
  It is definitely not "just a few". I'm working for a domain registrar and can confirm that most registries support DNSSEC nowadays.
- tptacek 3y ago
  Of course they support DNSSEC. It's a government controlled key escrow system for those domains. I'm surprised they haven't tried to mandate its adoption by statute.
  - cyberax 3y ago
    ??? You don't escrow your private keys with DNSSEC. Neither is it "government controlled".
    - tptacek 3y ago
      Governments control the roots! If they want the DNS PKI to assert that a host they control is MAIL.GOOGLE.COM, to a particular target, they can do that. They cannot trivially do that with the Web PKI.
      - cyberax 3y ago
        You don't understand how DNS works. The root is controlled by a US organization (not the government, but whatever) and it delegates individual TLDs to other organizations in other jurisdictions. So if the US government wants to fake (for example) mail.google.cz it needs to: 1. Create a fake .cz record and sign it with the root KSK. 2. Make sure only you see this record (so they must control the network path to you). 3. Create a fake response. This is technically possible, but highly unlikely. It's also going to be very visible and easily detectable.
silisili 3y ago
> The worst part is actually that very few of the TLD support dnssec Almost every TLD does. What in the world prompted such a statement?

jedisct1 3y ago

> DNSCrypt? Sounds good, but the server key is published in the NS record, which gets published in the old cleartext DNS What is published in DNS records are the public certificates, not their signatures.

Luker88 3y ago
yes, but that was my point. You publish on an unsecure channel(DNS) the public key. Then, after the resolver gets the key, everything is safe. But getting the key might not be safe at all. DNSCrypt has been out a couple of years but does not yet have a standard RFC and is not used by the dns root servers. Or did I miss something in the chain of trust?
- jedisct1 3y ago
  > DNSCrypt has been out a couple of years but does not yet have a standard RFC https://datatracker.ietf.org/doc/draft-denis-dprive-dnscrypt/ https://datatracker.ietf.org/doc/draft-denis-dprive-dnscrypt... It's not used by DNS root servers because it's designed to secure communications between clients and caches, not between caches and authoritative servers.

hannob 3y ago

> But what alternative is there for securing the dns chain? You're asking the wrong question. The better question would be: What do I want to achieve by securing the DNS chain, and can I do that in a different way? What you ultimately want is to make sure you're communicating with the correct other party. And the way to achieve this is TLS with certificates, validated via the WebPKI. I'm not saying TLS+WebPKI is perfect. But it works certainly a lot better than DNSSEC (which, let's be honest, does not work in practice).

cyberax 3y ago
> What do I want to achieve by securing the DNS chain, and can I do that in a different way? Ability to ditch the CA infrastructure with DANE.
- hannob 3y ago
  Yeah, ok, but then you need to ask if DANE achieves that. And the answer to that is clearly "no". DANE never made it past an experimental browser plugin, and as far as I know that isn't even developed any more. In the time where DANE achieved nothing, we got Let's Encrypt, we got CT, and a whole bunch of other improvements to the WebPKI.
  - cyberax 3y ago
    DANE technically achieved that, I played around with OpenSSL plugin for DANE back in 2010 (when the . was signed). But yeah, I get your point. Right now, the path ahead is stapled DANE TLS extension. Basically, the idea is that you can use simple unauthenticated DNS to get the domain name, just like now. Then you get the complete DNSSEC-authenticated DNS chain for the DANE record as a part of the TLS handshake: https://datatracker.ietf.org/doc/rfc9102/ https://datatracker.ietf.org/doc/rfc9102/ This seems to be the best of both worlds: 1. We keep DNS as a simple and nimble UDP-based service, without trying to cram the signature in each packet. 2. Since we HAVE to use TLS anyway to achieve any meaningful security, we can just transmit the full DNS chain (up to the root zone!) with signatures easily as a part of the TLS handshake. 3. The client then just needs to validate this chain, and it only needs to have the root zone's key as the root of trust. 4. The root zone's key changes fairly infrequently (once in a decade), so IoT devices can use it to bootstrap themselves.
    - AndyMcConachie 3y ago
      > 4. The root zone's key changes fairly infrequently (once in a decade), so IoT devices can use it to bootstrap themselves. This is not true, nor will it be true into the future.

cyberax 3y ago

> The worst part is actually that very few of the TLD support dnssec ??? All the "regular" TLDs support DNSSEC: .com, .net, .org, co.uk

chkal 3y ago
It is definitely not "just a few". I'm working for a domain registrar and can confirm that most registries support DNSSEC nowadays.
tptacek 3y ago
Of course they support DNSSEC. It's a government controlled key escrow system for those domains. I'm surprised they haven't tried to mandate its adoption by statute.
- cyberax 3y ago
  ??? You don't escrow your private keys with DNSSEC. Neither is it "government controlled".
  - tptacek 3y ago
    Governments control the roots! If they want the DNS PKI to assert that a host they control is MAIL.GOOGLE.COM, to a particular target, they can do that. They cannot trivially do that with the Web PKI.
    - cyberax 3y ago
      You don't understand how DNS works. The root is controlled by a US organization (not the government, but whatever) and it delegates individual TLDs to other organizations in other jurisdictions. So if the US government wants to fake (for example) mail.google.cz it needs to: 1. Create a fake .cz record and sign it with the root KSK. 2. Make sure only you see this record (so they must control the network path to you). 3. Create a fake response. This is technically possible, but highly unlikely. It's also going to be very visible and easily detectable.

silisili 3y ago

> The worst part is actually that very few of the TLD support dnssec Almost every TLD does. What in the world prompted such a statement?