💾 Archived View for rawtext.club › ~sloum › geminilist › 002130.gmi captured on 2020-09-24 at 01:24:49. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Thomas Karpiniec tom.karpiniec at outlook.com
Thu Jul 9 01:39:04 BST 2020
- - - - - - - - - - - - - - - - - - -
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.
Cheers, Tom