5 ms·

> As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less er

by growse 6mo ago

> As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone. Ah yes. Let's take something that's prone to causing service issues and strap more footguns to it. It's not worth it, because the cost is extremely quantifiable and visible, whereas the benefits struggle to be coherent.

indolering 6mo ago
The benefits are huge: there are lots of attacks that DNSSEC trivially prevents and it would help secure more than just web browsers.
- ekr____ 6mo ago
  Can you expand on this a bit, under the assumption that the traffic is using some form of transport security (e.g., TLS, SSH, etc.)?
  - indolering 6mo ago
    DNS underlies domain authority and the validity of every connection to every domain name ultimately traces back to DNS records. The amount of infra needed to shore up HTTPS is huge and thus SSH and other protocols rely on trust-on-first-use (unless you manually hard-code public keys yourself - which doesn't happen). DNS offers a standard, delegable PKI that is available to all clients regardless of the transport protocol. With DNSSEC, a host with control over a domain's DNS records could use that to issue verifiable public keys without having to contact a third party. I ran into this while working on decentralized web technologies and building a parallel to WebPKI just wasn't feasible. Whereas we could totally feed clients DNSSEC validated certs, but it wasn't supported.
    - ekr____ 6mo ago
      Thanks for the explanation. It seems like there are two cases here: 1. Things that use TLS and hence the WebPKI 2. Other things. None of what you've written here applies to the TLS and WebPKI case, so I'm going to take it that you're not arguing that DNSSEC validation by clients provides a security improvement in that case. That leaves us with the non-WebPKI cases like SSH. I think you've got a somewhat stronger case there, but not much of one, because those cases can also basically go back to the WebPKI, either directly, by using WebPKI-based certificates, or indirectly, by hosting fingerprints on a Web server.
      - tptacek 6mo ago
        In practice, fleet operators run their own PKIs for SSH, so tying them to the DNSSEC PKI is a strict step backwards for SSH security. There may be other applications where a global public PKI makes sense; presumably those applications will be characterized by the need to make frequent introductions between unrelated parties, which is distinctly not an attribute of the SSH problem.
        indolering 6mo ago
        And for everyone else that just wants to connect to an SSH session without having to setup PKI themselves? Tying that to the records used to find the domain seems like the obvious place to put that information to me! DNSSEC lets you delegate a subtree in the namespace to a given public key. You can hardcode your DNSSEC signing key for clients too. Don't get me started on how badly VPN PKI is handled....
        tptacek 6mo ago
        Yes, modern fleetwide SSH PKIs all do this; what you're describing is table stakes and doesn't involve anybody delegating any part of their security to a global PKI run by other organizations. The WebPKI and DNSSEC run global PKIs because they routinely introduce untrusting strangers to each other. That's precisely not the SSH problem. Anything you do to bring up a new physical (or virtual) involves installing trust anchors on it; if you're in that position already, it actually harms security to have it trust a global public PKI. The arguments for things like SSHFP and SSH-via-DNSSEC are really telling. It's like arguing that code signing certificates should be in the DNS PKI.
        indolering 6mo ago
        DNSSEC PKI does not preclude one from hardcoding specific keys in the client as well. Providing global PKI and enabling end-to-end authentication by default for all clients and protocols certainly would make the internet a safer place.

by growse 6mo ago

indolering 6mo ago

The benefits are huge: there are lots of attacks that DNSSEC trivially prevents and it would help secure more than just web browsers.

ekr____ 6mo ago
Can you expand on this a bit, under the assumption that the traffic is using some form of transport security (e.g., TLS, SSH, etc.)?
- indolering 6mo ago
  DNS underlies domain authority and the validity of every connection to every domain name ultimately traces back to DNS records. The amount of infra needed to shore up HTTPS is huge and thus SSH and other protocols rely on trust-on-first-use (unless you manually hard-code public keys yourself - which doesn't happen). DNS offers a standard, delegable PKI that is available to all clients regardless of the transport protocol. With DNSSEC, a host with control over a domain's DNS records could use that to issue verifiable public keys without having to contact a third party. I ran into this while working on decentralized web technologies and building a parallel to WebPKI just wasn't feasible. Whereas we could totally feed clients DNSSEC validated certs, but it wasn't supported.
  - ekr____ 6mo ago
    Thanks for the explanation. It seems like there are two cases here: 1. Things that use TLS and hence the WebPKI 2. Other things. None of what you've written here applies to the TLS and WebPKI case, so I'm going to take it that you're not arguing that DNSSEC validation by clients provides a security improvement in that case. That leaves us with the non-WebPKI cases like SSH. I think you've got a somewhat stronger case there, but not much of one, because those cases can also basically go back to the WebPKI, either directly, by using WebPKI-based certificates, or indirectly, by hosting fingerprints on a Web server.
    - tptacek 6mo ago
      In practice, fleet operators run their own PKIs for SSH, so tying them to the DNSSEC PKI is a strict step backwards for SSH security. There may be other applications where a global public PKI makes sense; presumably those applications will be characterized by the need to make frequent introductions between unrelated parties, which is distinctly not an attribute of the SSH problem.
      - indolering 6mo ago
        And for everyone else that just wants to connect to an SSH session without having to setup PKI themselves? Tying that to the records used to find the domain seems like the obvious place to put that information to me! DNSSEC lets you delegate a subtree in the namespace to a given public key. You can hardcode your DNSSEC signing key for clients too. Don't get me started on how badly VPN PKI is handled....
        tptacek 6mo ago
        Yes, modern fleetwide SSH PKIs all do this; what you're describing is table stakes and doesn't involve anybody delegating any part of their security to a global PKI run by other organizations. The WebPKI and DNSSEC run global PKIs because they routinely introduce untrusting strangers to each other. That's precisely not the SSH problem. Anything you do to bring up a new physical (or virtual) involves installing trust anchors on it; if you're in that position already, it actually harms security to have it trust a global public PKI. The arguments for things like SSHFP and SSH-via-DNSSEC are really telling. It's like arguing that code signing certificates should be in the DNS PKI.
        indolering 6mo ago
        DNSSEC PKI does not preclude one from hardcoding specific keys in the client as well. Providing global PKI and enabling end-to-end authentication by default for all clients and protocols certainly would make the internet a safer place.