> but it's a pragmatic ...
I think we have different views of the word pragmatic if your pragmatic solution covers including a HTTP server in OpenSSH for serving a single (!) file while the other solution depends on something you most probably already use to connect to the server (DNS).
The harder parts are what is the client going to do, and how will you implement TLS at each end? For the client, you’ll want to link against an HTTP library that integrates with the client OS’s x509 PKI as that will be the axiom upon which your trust of the server is founded. Their host key was served in a connection signed by Let’s Encrypt, and you’ve got Let’s Encrypt in /etc/ssl/cacerts.pem or whatever.
The hardest part is adding a TLS implementation to OpenSSH and the crazy part is having it support ACME so it can fetch its own certificates**. There is precedent for this though — caddy includes support for negotiating issuance and renewal of SSL certificates via ACME:
Adding a new feature like this comes with the responsibility of supporting it in production and fixing bugs (in this case, dealing with weird missing features) for the remaining lifetime of the product. It’s not something to be done as lightly as an HN comment, by any means. There are a lot of sensible reasons to use DNS to bootstrap trust but as others have pointed out it is a little naive to think that DNSSEC has anything like the level of deployment that HTTPS has achieved since ACME and Lets Encrypt showed up. I contend that it’s that aspect which makes my solution indeed a more practical method — pragmatic, even — of bootstrapping trust over The Internet in 2023.
* Yes, this will mean you cannot support clients that demand their content be encoded with xzip in ylang with zspace. We’re not writing a real httpd here, remember.
** If it’s using ACME HTTP then that makes the simplistic httpd a bit more complicated, of course. Now you have to blurt two responses instead of one.
It's a shame that OpenSSH can't use those directly. "ssh-keygen -i" can import individual keys, but alas - SSH certificate signatures are generated differently from X.509 certs.
The OpenSSH daemon could host it for you if you could fit a tiny, vuln free httpd inside it — not an enormously onerous task given that the codebase already includes the implementation of a robust TCP daemon. Add ACME support and you’ve moved the TOFU MITM attack from being possible on every-new-client-connection to also having to coincide with the once-every-X-days for the HTTPS certificate renewal.
It’s a lot of new functionality which probably isn’t cool for the OpenSSH codebase, but it’s a pragmatic solution to plugging the gap between mankind’s universally deployed PKI and ssh’s ephemeral peer-to-peer verification.