💾 Archived View for rawtext.club › ~sloum › geminilist › 002099.gmi captured on 2020-09-24 at 03:21:46. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Thomas Karpiniec tom.karpiniec at outlook.com
Tue Jul 7 05:26:48 BST 2020
- - - - - - - - - - - - - - - - - - -
From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of
colecmac at protonmail.com
How can a server rotate a keypair and prove it's still the same server as
before, that there's not an MITM attack going on? This is a genuine question,
I haven't heard much about key rotation for TLS before. Could you explain or
send a link on how this works? I can't find much on it.
This thread feels like it's trying to hack certificate validation into doing something for which it really wasn't intended, operating without a CA. Getting this right is likely to be more complicated than any aspect of the Gemini protocol itself.
The spec:
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).
Could I gently push back on the idea that getting an LE certificate is a high barrier to entry? Configuring certbot is relatively easy and a known quantity. Cleaning up after my private key is lost or exposed is an open ended problem with no easy solutions. I know there is a diversity of opinions/priorities but my vote would be to lean on the regular CA infrastructure so that we don't have to tussle with all of the scenarios currently being discussed.
More broadly, Gemini is a magnificent hack to co-opt the best of both gopher and the web into a carefully calibrated new thing, leaning on existing technologies like URLs, MIME types and TLS for expedience. LetsEncrypt is a magnificent hack to the CA system, providing all the benefits to us at no monetary cost, and that was no small undertaking. I don't think it should fall to Gemini, and therefore the implementors of Gemini clients and servers, to "fix" TLS trust. A good solution, once it is actually adopted, is likely to apply to all TLS servers rather than Gemini alone. Provided we are using TLS libraries we can take advantage of whatever that happens to be.
If nothing else, clients could attempt to verify the provided cert/chain against the system's trusted root CAs. If this takes precedence over TOFU it offers an escape hatch for anybody who wanted to try the self-signed thing and then it didn't work out. Nothing I've suggested here is _contrary_ to the spec as it stands - it's just a question of what people do by default, which hopefully won't set them up for failure later.
Cheers, Tom