4 ms·

This drills into the core problem: technologists like you look at DNSSEC and say "there is a problem, something must be done, this is something". But it's not e

by tptacek 8mo ago

This drills into the core problem: technologists like you look at DNSSEC and say "there is a problem, something must be done, this is something". But it's not enough to identify a problem and solution. The solution has to be worth the cost. Rollout can't be more costly than the original problem. There's ample evidence that the cost/benefit math simply doesn't work out for DNSSEC. You can design new DNSSECs with different cost profiles. I think a problem you'll run into is that the cost of the problem it solves is very low, so you won't have much headroom to maneuver in. But I'm not reflexively against ground-up retakes on DNSSEC. Where you'll see viscerally negative takes from me is on attempts to take the current gravely flawed design --- offline signers+authenticated denial --- as a basis for those new solutions. The DNSSEC we're working with now has failed in the marketplace. In fact, it's failed more comprehensively than any IETF technology ever attempted: DNSSEC dates back into the early-mid 1990s. It's long past time to cut bait.

ekr____ 8mo ago
> In fact, it's failed more comprehensively than any IETF technology ever attempted Now here is where I disagree. Just off the top of my head, how about HIP, IP multicast and PEM?
- tptacek 8mo ago
  PEM actually gets used? People depend on it? It hasn't been a market success, but if the root keys for DNSSEC ended up on Pastebin this evening, almost nobody would need to be paged, and you can't say that about PEM. Multicast gets used (I think unwisely) in campus/datacenter scenarios. Interdomain multicast was a total failure, but interdomain multicast is more recent than DNSSEC. HIP is mid-aughts, isn't it?
  - ekr____ 8mo ago
    Fair enough on Multicast and HIP. I'm less sure about the case for PEM. S-HTTP was a bigger failure in absolute terms (I should know!) but it was eventually published as Experimental and the IETF never really pushed it, so I don't think you could argue it was a bigger failure overall.
    - tptacek 8mo ago
      There really has been a 30+ year full-court press to make DNSSEC happen, including high-effort coordination with both operators and developers. I think the only comparable effort might be IPv6. But IPv6 is succeeding (slowly), and DNSSEC seems to have finally failed. (I hate to IETFsplain anything to you so think of this as me baiting you into correcting me.)
      - ekr____ 8mo ago
        Oh, I was basically agreeing with you. To really nerd out about it, it seems to me there are two metrics. 1. How much it failed (i.e., how low adoption was). 2. How much effort the IETF and others put into selling it. From that perspective, I think DNSSEC is the clear winner. There are other IETF protocols that have less usage, but none that have had anywhere near the amount of thrust applied as DNSSEC.
cyberax 8mo ago
> There's ample evidence that the cost/benefit math simply doesn't work out for DNSSEC. Why? What is the real difference between DNSSEC and HTTPS? I'd argue that the only difference is that browser vendors care about protecting against MITM on the client side. They're fine with MITM on the server side or with (potentially state-sponsored) BGP prefix hijacks. And I'm not fine with that personally. > Where you'll see viscerally negative takes from me is on attempts to take the current gravely flawed design --- offline signers+authenticated denial --- as a basis for those new solutions. Yes, I agree with that. In particular, NSEC3 was a huge mistake, along with the complexity it added. I think that we should have stuck with NSEC for the cases where enumeration is OK or with a "black lies"-like approach and online signing. It's also ironic because now many companies proactively publish all their internal names in the CT logs, so attackers don't even need to interact with the target's DNS to find out all its internal names. > In fact, it's failed more comprehensively than any IETF technology ever attempted: DNSSEC dates back into the early-mid 1990s. It's long past time to cut bait. I would say that IPv6 failed even more. It's also unfair to say that DNSSEC dates back to the 90-s, the root zone was signed only in 2008. The good news is that DNSSEC can be improved a lot by just deprecating bad practices. And this will improve DNS robustness in general, regardless of DNSSEC use.
- tptacek 8mo ago
  Seriously? I'll give you two differences right off the bat: 1. DNSSEC only protects the name lookup for a host, and TLS/HTTPS protects the entire session. 2. People actually rely on TLS/HTTPS, and nobody relies on DNSSEC, to the point where the root keys for DNSSEC could be posted on Pastebin tonight and almost nobody would have to be paged. If the private key for a CA in any mainstream browser root program got published that way, it would be all hands on deck across the whole industry.
  - indolering 8mo ago
    > DNSSEC only protects the name lookup for a host, and TLS/HTTPS protects the entire session. It only provides privacy, it doesn't verify that the resolver didn't tamper with the record. >to the point where the root keys for DNSSEC could be posted on Pastebin tonight and almost nobody would have to be paged. This would very much be a major issue and lots of people would immediately scramble to address it. The root servers are very highly audited and there is an absurd amount of protocol and oversight of the process.

by tptacek 8mo ago

ekr____ 8mo ago

> In fact, it's failed more comprehensively than any IETF technology ever attempted Now here is where I disagree. Just off the top of my head, how about HIP, IP multicast and PEM?

tptacek 8mo ago
PEM actually gets used? People depend on it? It hasn't been a market success, but if the root keys for DNSSEC ended up on Pastebin this evening, almost nobody would need to be paged, and you can't say that about PEM. Multicast gets used (I think unwisely) in campus/datacenter scenarios. Interdomain multicast was a total failure, but interdomain multicast is more recent than DNSSEC. HIP is mid-aughts, isn't it?
- ekr____ 8mo ago
  Fair enough on Multicast and HIP. I'm less sure about the case for PEM. S-HTTP was a bigger failure in absolute terms (I should know!) but it was eventually published as Experimental and the IETF never really pushed it, so I don't think you could argue it was a bigger failure overall.
  - tptacek 8mo ago
    There really has been a 30+ year full-court press to make DNSSEC happen, including high-effort coordination with both operators and developers. I think the only comparable effort might be IPv6. But IPv6 is succeeding (slowly), and DNSSEC seems to have finally failed. (I hate to IETFsplain anything to you so think of this as me baiting you into correcting me.)
    - ekr____ 8mo ago
      Oh, I was basically agreeing with you. To really nerd out about it, it seems to me there are two metrics. 1. How much it failed (i.e., how low adoption was). 2. How much effort the IETF and others put into selling it. From that perspective, I think DNSSEC is the clear winner. There are other IETF protocols that have less usage, but none that have had anywhere near the amount of thrust applied as DNSSEC.

cyberax 8mo ago

> There's ample evidence that the cost/benefit math simply doesn't work out for DNSSEC. Why? What is the real difference between DNSSEC and HTTPS? I'd argue that the only difference is that browser vendors care about protecting against MITM on the client side. They're fine with MITM on the server side or with (potentially state-sponsored) BGP prefix hijacks. And I'm not fine with that personally. > Where you'll see viscerally negative takes from me is on attempts to take the current gravely flawed design --- offline signers+authenticated denial --- as a basis for those new solutions. Yes, I agree with that. In particular, NSEC3 was a huge mistake, along with the complexity it added. I think that we should have stuck with NSEC for the cases where enumeration is OK or with a "black lies"-like approach and online signing. It's also ironic because now many companies proactively publish all their internal names in the CT logs, so attackers don't even need to interact with the target's DNS to find out all its internal names. > In fact, it's failed more comprehensively than any IETF technology ever attempted: DNSSEC dates back into the early-mid 1990s. It's long past time to cut bait. I would say that IPv6 failed even more. It's also unfair to say that DNSSEC dates back to the 90-s, the root zone was signed only in 2008. The good news is that DNSSEC can be improved a lot by just deprecating bad practices. And this will improve DNS robustness in general, regardless of DNSSEC use.

tptacek 8mo ago
Seriously? I'll give you two differences right off the bat: 1. DNSSEC only protects the name lookup for a host, and TLS/HTTPS protects the entire session. 2. People actually rely on TLS/HTTPS, and nobody relies on DNSSEC, to the point where the root keys for DNSSEC could be posted on Pastebin tonight and almost nobody would have to be paged. If the private key for a CA in any mainstream browser root program got published that way, it would be all hands on deck across the whole industry.
- indolering 8mo ago
  > DNSSEC only protects the name lookup for a host, and TLS/HTTPS protects the entire session. It only provides privacy, it doesn't verify that the resolver didn't tamper with the record. >to the point where the root keys for DNSSEC could be posted on Pastebin tonight and almost nobody would have to be paged. This would very much be a major issue and lots of people would immediately scramble to address it. The root servers are very highly audited and there is an absurd amount of protocol and oversight of the process.