Removing expiry dates for TOFU

[Thomas Karpiniec]

> From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of Solderpunk
> A proposal: "TOFU-TOTS".  You know, like tater tots, but without
> potatoes in them.  Or rather, trust-on-first-use augmented by
> trust-over-time-and-space.

Setting aside that I already put my support behind the oligarchy, this is an interesting problem and I'll weigh in. :)

I agree that that this proposal would provide fairly effective protection against MITM. I worry that it is so unusual that it would push newbies away from setting up gemini servers. Faced with regular rotation requirements I suspect that many people would automate the process with cronjobs, meaning that the keys for the next certificate are sitting right there on the server ready to be nabbed.

More annoyingly, suppose the current private key is compromised and the legitimate server owner realises it - they don't have any good options. One is to put up with being spoofable until their next-advertised certificate becomes valid, which may be 10 months in the future. Otherwise they could do an out-of-turn certificate rotation, which clients will warn on just as harshly as any other unexpected change. (Further down the thread, Baschdel suggested backup certificates to alleviate this. But what if you're compromised twice? To me the complexity creep feels disproportionate to the advantages.)

A suggestion: what if instead of publishing a future certificate, we publish our own CA certificate, which is used to sign our server certificates? A client should cache this CA certificate permanently and use it to verify all future requests to that domain. A diligent system administrator will keep their CA key material offline. Someone who doesn't care so much can just generate everything on their server.

* Client logic is simpler
* Keys and certificates can be rotated at will by the sysadmin and they can choose whatever expiry they are comfortable with
* Relies on familiar concepts of TLS trust ("oh I'm my own CA, okay") and sysadmins can choose their own level of caution
* Uses the existing feature of TLS libraries to verify a connection against a given CA. Clients don't have to handle public keys or fingerprints - they just download the CA certificate and feed it into their TLS library.
* Combines neatly with LetsEncrypt-style certificate management - you are just adding one extra trusted CA. If it can be verified by either that, or one of the normal roots, then you're okay.
* Only slightly more complicated openssl commands required when setting up a server

Cheers, Tom