4 ms·

Your objections basically boil down to: DNS is dangerous, and DNSSEC _is_ DNS. This is fair, but the conclusion for me is that we need to make _DNS_ more reliab

by cyberax 8mo ago

Your objections basically boil down to: DNS is dangerous, and DNSSEC _is_ DNS. This is fair, but the conclusion for me is that we need to make _DNS_ more reliable. Not to keep treating it as a fragile Ming Dynasty vase. In particular, the long TTL of DNS records itself is a historic artifact and should be phased out. There's absolutely no reason to keep it above ~15 minutes for the leaf zones. The overhead of doing additional DNS lookups is completely negligible. > This isn't so much as a scary story I'm telling so much as it is an empirically observable fact; it's happened many times, to very important domains, over the last several years. So has the TLS cert expiration. And while you can (usually) click through it in browsers, it's not the case for mobile apps or for IoT/embedded devices. Or even for JS-rich webapps that use XMLHttpRequest/fetch. And we keep making Internet more fragile with the ".well-known" subtrees that are served over TLS. It's also now trivial for me to get a certificate for most domains if I can MITM their network. Edit: BTW, what is exactly _expiring_ in DNSSEC? I've been using the same private key on my HSM for DNSSEC signing for the last decade. You also can set up signing once, and then never touch it.

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.

by cyberax 8mo ago

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.