Again, that's part of the Gemini spec.

> 4.2 Server certificate validation

> Clients can validate TLS connections however they like (including not at all) but the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens. This greatly reduces TLS overhead on the network (only one cert needs to be sent, not a whole chain) and lowers the barrier to entry for setting up a Gemini site (no need to pay a CA or setup a Let's Encrypt cron job, just make a cert and go).

> TOFU stands for "Trust On First Use" and is public-key security model similar to that used by OpenSSH. The first time a Gemini client connects to a server, it accepts whatever certificate it is presented. That certificate's fingerprint and expiry date are saved in a persistent database (like the .known_hosts file for SSH), associated with the server's hostname. On all subsequent connections to that hostname, the received certificate's fingerprint is computed and compared to the one in the database. If the certificate is not the one previously received, but the previous certificate's expiry date has not passed, the user is shown a warning, analogous to the one web browser users are shown when receiving a certificate without a signature chain leading to a trusted CA.

> This model is by no means perfect, but it is not awful and is vastly superior to just accepting self-signed certificates unconditionally.

That is a terrible security assessment and it is an awful model for the web.

OpenSSH's TOFU works in its specific context primarily because SSH targets have been connected to beforehand and you can't place an evil proxy between. In order to prevent issues with TOFU, we've got SSHFP DNS records (so, trusting DNSSEC).

Now with the web, it's already rather ridiculous to suggest that it's not a terrible security model to not visit any new websites on untrusted connections. Plus the seeming lack of alternative methods (like SSHFP/TLSA + DNSSEC) to establish trust with untrustworthy networks (which well, most networks should be considered as).

Giving the DNS PKI any influence over your SSH connections seems insane, since there is literally no reason whatsoever the DNS root and TLD operators should have any say whatsoever in how you connect to your own servers.

If you're worried about key continuity issues, do what large SSH fleet deployers do, and use certificates. Key continuity was the motivating use case for SSH certificates, before they were used to do MFA/SSO logins for users.

I don't disagree with the analysis of Gemini's trust model; I think you're right that key continuity doesn't work on the scale of the public web. Of course, I don't think DNSSEC has any answers here, either; the Web PKI is probably the best thing we've got right now.

I just highlighted the fact that OpenSSH (which was an inspiration to the Gemini people) finds this an issue and have devised solutions. You and everyone else are absolutely free to not to trust DNSSEC and deal with the pitfalls of TOFU-over-internet in some other way.

Though in theory, just using SSHFP+DNSSEC and those operators being malicious shouldn't degrade SSH's security, it should only hinder the same TOFU. In which case I suspect people would fall back to the Web PKI to look up the reason for the mismatch.