A thought from one without enough knowledge to have a right to thoughts:
Getting broad acceptance of Gemini both theoretically as a viable
standard and practically as a growing community is important. Having
community members developing their own clients and servers - not so much.
I am sure I will always be using a client which someone else wrote, just
as I use a web browser someone else wrote. And I am dead certain I will
never try to write my own server, as I will never try to write my own
Apache.
Best to all,
Terry B.
On 07/08/2020 08:39 PM, Thomas Karpiniec wrote:
>> 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
---
Previous in thread (35 of 37): 🗣️ Hannu Hartikainen (hannu.hartikainen+gemini (a) gmail.com)
Next in thread (37 of 37): 🗣️ Solderpunk (solderpunk (a) posteo.net)