On Tue Jul 7, 2020 at 6:26 AM CEST, Thomas Karpiniec wrote: > 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. This opinion has been expressed in the past - in fact, by Michael Lazar if I remember rightly? The extent to which Geminispace at large has been interested in trying to breakaway from the "centralised oligarchy of CAs" has changed. I'd love to have detail stats on the actual proportion of servers using self-signed vs CA-signd certs over time! There seems to be more enthusiasm behind TOFU at the moment than at other times in the relatively recent past. The spec is deliberately, for now, quite open ended on this. I didn't want to force people to implement TOFU, which has proven less trivial than I first imagined. But I also didn't want server operators who do choose to experiment with it to become second class citizens of Geminispace, with most clients throwing up scary warnings every time. > 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 In generally agree with you here. This allows folks without philosophical/political axes to grind to just setup certbot and know it will work smoothly (which it doesn't with pure TOFU clients, which will trigger warnings regularly) The only reason AV-98 doesn't do this, and forces you to manually switch between the two modes, is that the standard Python ssl module doesn't allow it (at least not gracefully, without making a new connection after one fails). > 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. I have been thinking this myself lately. Not that I want to give up on TOFU, but that all the more clever/elegant ways of doing it which involve certificate chains are actually not the way to go: they might be solid security wise, but no TLS library is going to support them out of the box. They *might* be easily implemented with a library which exposes signature validation functions nicely, but those will be rare, and further more programmers who understand how to do that properly will be even rarer, running the risk of bad implementations. My current thinking is that any recommended approach should avoid treating certificates as anything more than than opaque binary blobs as much as possible (for the purposes of trust management, I mean). The various ideas around serving future certificates on a well-known endpoint for some time before they become valid fits in with this. It just involves fetching a pile of bytes and hashing it, no understanding of keys/signing on the part of the client author required... > A good solution, once it > is actually adopted, is likely to apply to all TLS servers rather than > Gemini alone. I'm not too sure about this. Solutions which work in an environment dominated by dissemination of publically available information (Geminispace, I hope) may not work acceptably well in an environment dominated by private conversations (email, and a lot of the web). I suspect it's a lot easier to come up with something relatively simple that works for us which most other TLS servers will be disinterested in. Cheers, Solderpunk
---
Previous in thread (13 of 37): 🗣️ Thomas Karpiniec (tom.karpiniec (a) outlook.com)
Next in thread (15 of 37): 🗣️ Solderpunk (solderpunk (a) posteo.net)