So: I wrote a blog post in January of 2015, and 7 months later you wrote a blog post responding to it in August of 2015, and 10 years later you're still angry that I didn't update my blog post to point to the post that you wrote?

I write things people disagree with all the time. I can't recall ever having been mad that people didn't cite me for things we disagree about. Should I have expected all the people who hated coding agents to update their articles when I wrote "My AI Skeptic Friends Are All Nuts"? I didn't realize I was supposed to be complaining about that.

> > LE isn't primarily funded by non-profits, as you can see from the sponsor list here: https://isrg.org/sponsors/ > > I mean, Mozilla got the ball rolling

Among others:

  Let’s Encrypt was created through the merging of two simultaneous
  efforts to build a fully automated certificate authority. In 2012, a
  group led by Alex Halderman at the University of Michigan and
  Peter Eckersley at EFF was developing a protocol for automatically
  issuing and renewing certificates. Simultaneously, a team at Mozilla
  led by Josh Aas and Eric Rescorla was working on creating a free
  and automated certificate authority. The groups learned of each
  other’s efforts and joined forces in May 2013.

  ...

  Initially, ISRG was funded almost entirely through large dona-
  tions from technology companies. In late 2014, it secured financial
  commitments from Akamai, Cisco, EFF, and Mozilla, allowing the
  organization to purchase equipment, secure hosting contracts, and
  pay initial staff. Today, ISRG has more diverse funding sources; in
  2018 it received 83% of its funding from corporate sponsors, 14%
  from grants and major gifts, and 3% from individual giving.

> and it's still run on donations (even if they come from private actors).

I agree, but I think it's important to be precise about what's happening here, and like I said, it's never been the case that LE was really funded by non-profits.

> > Like I said, it may be cheaper in aggregate, but I think you'd need to make that case. > > The PKI is already there: we have 7 people who can do a multisig for new root keys. There is a signing ceremony in a secure bunker somewhere that gets live streamed. The HSMs and servers are already paid for. Cert transparency/monitoring is nice but now it's hard-coded to HTTPS instead of being done more generically. There's a lot of duplicated effort.

I think this is a category error. The main operational cost for DNSSEC is not really the root, which is comparatively low load, but rather the distributed operations for every registry/registrar, and server to register keys, sign domains, etc.

One way to think about this is that running a TLD with DNSSEC is conceptually similar to operating a CA in that you have to take in everyone's keys and sign them. It's true you don't need to validate their domains, but that's not the expensive part. Operating this machinery isn't free, especially when you have to handle exceptional cases like people who screw up their domains and need manual help to recover. Now, it's possible that it's a marginal incremental cost, but I doubt it's zero. Upthread, you suggested that people are already paying for this in their domain registrations, but that just means that the TLD operator is going to have to absorb the incremental cost.

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.

> 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.

It would benefit the likes of Wikileaks. You could do all the crypto in your basement with an HSM without involving anyone else.

> 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.

But do they? That requires adding support for another protocol.

I would like to live in a world where I don't have to copy/paste SSH keys from an AWS console just to have the piece-of-mind that my SSH connection hasn't been hijacked.