5 ms·

While this is true, what DNSSec solves is the distribution of trusted identity. It's one of the lowest layers in the Internet, if you can hijack DNS, then all

While this is true, what DNSSec solves is the distribution of trusted identity. It's one of the lowest layers in the Internet, if you can hijack DNS, then all connections the client is routed to can be used to exploit higher level security features like TLS. Yes, things like pinning of certificates can reduce this, but all a bad actor needs to do is get access to a poorly managed x509 trusted cert. DNSSec does offer a layer of trust that most people lack today.

CiPHPerCoder 10y ago
> While this is true, what DNSSec solves is the distribution of trusted identity. Attempts to solve. I don't trust identities just because the US government tells me to do so. I believe certificate transparency + ubiquitous TLS + RFC 7858 (or DNSCurve/DNSCrypt) is a better cocktail.
ryanlol 10y ago
>DNSSec does offer a layer of trust that most people lack today. A comforting 1024bit RSA blanket.
- marcosdumay 10y ago
  Looks like this is about to change.
  - ryanlol 10y ago
    In the context on DNSSEC "about to" is decades.
tptacek 10y ago
You trust Verisign? You trust the USG? You trust the UK? DNSSEC was hijacked --- by old-school Unix people in the IETF who loathe X.509 on aesthetic grounds and by the USG, which attempted to mandate DNSSEC --- to integrate with and replace X.509 CAs. You write as if DNSSEC could be deployed alongside the X.509 CA hierarchy. No. On the real-world Internet, browser trust validation has to work for everyone, or it doesn't work at all. Common-sense workarounds, like "we'll do DANE for the people who can do DANE, and then fall back to CA validation" fall apart when confronted with adversaries. Anything you "fall back" to becomes the default for purposes of security, because attackers will launch downgrade attacks to make that happen. Don't take my word for this: https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html The net result is: DANE doesn't collapse Internet trust down to a single point; rather, it provides us with a 1036th CA. One that just happens to be run by world governments.
- bluejekyll 10y ago
  If I understand your basic argument, it's that shit is broken, and so fuck it, we'll just not bother with it. At what point do we decide that we should fix it? New DNS record types not being returned, yes this sucks, it means there are a lot of firewalls and resolvers that need to be fixed. But IPv6 has the same upward battle in terms of router support, finally making a lot of headway. As people start demanding DNSSec, anything that is blocking that will need to be fixed. RSA 1024 keys should be replaced, but again, we should be working to fix this, should we not? > it provides us with a 1036th CA. One that just happens to be run by world governments. Validating a different set of data though. On top of that, TLD's can start to be ranked based on their reputation. Just because things don't look good right now, doesn't mean that we can't work to fix them and make them better. Similarly we need to start pushing for BGP to get secured, as attacks on that network are significantly on the rise. I don't think we should just ignore the lower stacks of the network.
  - tptacek 10y ago
    DNSSEC has no meaningful real-world deployment. Nobody on the entire Internet has ever been protected by a DNSSEC validation. So if we're just going to fix things and make them better, let's fix the protocol, instead of deploying something that is broken and obsolete before anyone even starts using it.
    - bluejekyll 10y ago
      Do you have any specific recommendations? Or something to point me to? I'd love to help fix the protocol.
      - tptacek 10y ago
        Sure. DNSSEC was designed in the early-mid 1990s on the premise of "pick two: offline signing, authenticated denial, secret hostnames". They picked offline signing and authenticated denial. They picked wrong: the protocol should be redesigned to assume online signers, taking advantage of cryptography in every transaction. Obviously, DNSSEC should provide query secrecy. Obviously, every DNSSEC transaction should be encrypted. That's functionality not present in DNSSEC that must be before the protocol can be taken seriously. Resolver-server encrypted transactions also solve the problem of endpoint signature validation (because there's no weak link between servers and clients anymore). Daniel Bernstein, among others, was smart enough to realize that if you encrypt the connection between a resolver and a server, you don't really even need signatures anymore: if every link in the resolution chain is encrypted, there's no straightforward place to launch spoofing attacks anymore. DNSSEC advocates will point out that this doesn't make injecting fake DNS records 100% impossible. But it makes it so difficult that it's not worth it to any plausible attacker. There's nothing you can do about the fact that DNS is a hierarchical PKI controlled by governments. DANE simply can't be made to work: DNS has no business holding TLS certificates.

CiPHPerCoder 10y ago

> While this is true, what DNSSec solves is the distribution of trusted identity. Attempts to solve. I don't trust identities just because the US government tells me to do so. I believe certificate transparency + ubiquitous TLS + RFC 7858 (or DNSCurve/DNSCrypt) is a better cocktail.

ryanlol 10y ago

>DNSSec does offer a layer of trust that most people lack today. A comforting 1024bit RSA blanket.

marcosdumay 10y ago
Looks like this is about to change.
- ryanlol 10y ago
  In the context on DNSSEC "about to" is decades.

tptacek 10y ago

You trust Verisign? You trust the USG? You trust the UK? DNSSEC was hijacked --- by old-school Unix people in the IETF who loathe X.509 on aesthetic grounds and by the USG, which attempted to mandate DNSSEC --- to integrate with and replace X.509 CAs. You write as if DNSSEC could be deployed alongside the X.509 CA hierarchy. No. On the real-world Internet, browser trust validation has to work for everyone, or it doesn't work at all. Common-sense workarounds, like "we'll do DANE for the people who can do DANE, and then fall back to CA validation" fall apart when confronted with adversaries. Anything you "fall back" to becomes the default for purposes of security, because attackers will launch downgrade attacks to make that happen. Don't take my word for this: https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html The net result is: DANE doesn't collapse Internet trust down to a single point; rather, it provides us with a 1036th CA. One that just happens to be run by world governments.

bluejekyll 10y ago
If I understand your basic argument, it's that shit is broken, and so fuck it, we'll just not bother with it. At what point do we decide that we should fix it? New DNS record types not being returned, yes this sucks, it means there are a lot of firewalls and resolvers that need to be fixed. But IPv6 has the same upward battle in terms of router support, finally making a lot of headway. As people start demanding DNSSec, anything that is blocking that will need to be fixed. RSA 1024 keys should be replaced, but again, we should be working to fix this, should we not? > it provides us with a 1036th CA. One that just happens to be run by world governments. Validating a different set of data though. On top of that, TLD's can start to be ranked based on their reputation. Just because things don't look good right now, doesn't mean that we can't work to fix them and make them better. Similarly we need to start pushing for BGP to get secured, as attacks on that network are significantly on the rise. I don't think we should just ignore the lower stacks of the network.
- tptacek 10y ago
  DNSSEC has no meaningful real-world deployment. Nobody on the entire Internet has ever been protected by a DNSSEC validation. So if we're just going to fix things and make them better, let's fix the protocol, instead of deploying something that is broken and obsolete before anyone even starts using it.
  - bluejekyll 10y ago
    Do you have any specific recommendations? Or something to point me to? I'd love to help fix the protocol.
    - tptacek 10y ago
      Sure. DNSSEC was designed in the early-mid 1990s on the premise of "pick two: offline signing, authenticated denial, secret hostnames". They picked offline signing and authenticated denial. They picked wrong: the protocol should be redesigned to assume online signers, taking advantage of cryptography in every transaction. Obviously, DNSSEC should provide query secrecy. Obviously, every DNSSEC transaction should be encrypted. That's functionality not present in DNSSEC that must be before the protocol can be taken seriously. Resolver-server encrypted transactions also solve the problem of endpoint signature validation (because there's no weak link between servers and clients anymore). Daniel Bernstein, among others, was smart enough to realize that if you encrypt the connection between a resolver and a server, you don't really even need signatures anymore: if every link in the resolution chain is encrypted, there's no straightforward place to launch spoofing attacks anymore. DNSSEC advocates will point out that this doesn't make injecting fake DNS records 100% impossible. But it makes it so difficult that it's not worth it to any plausible attacker. There's nothing you can do about the fact that DNS is a hierarchical PKI controlled by governments. DANE simply can't be made to work: DNS has no business holding TLS certificates.