TLS, TOFU and the Gemini security model

I want to push back on the idea of TOFU certificates a little bit. Mainly, I
feel like I'm missing some important context that led to this decision of
rolling your own security model.

> Simplicity:
>
> * It should be possible for somebody who had no part in designing the
>   protocol to accurately hold the entire protocol spec in their head
>   after reading a well-written description of it once or twice.
> * A basic but usable (not ultra-spartan) client should fit comfortably
>   within 50 or so lines of code in a modern high-level language.
>   Certainly not more than 100.
> * A client comfortable for daily use which implements every single
>   protocol feature should be a feasible weekend programming project
>   for a single developer.

Why not just use PKI/TLS and be done with it? It seems like this would be the
most obvious and easiest to implement solution for both clients and servers.
Setting up Let's Encrypt is about as difficult as setting up a self-signed
certificate (correctly). I would wager that most servers running gemini will
already be running HTTPS anyway, so it won't even require any extra effort.
Your operating system already has the trusted root CAs installed. OpenSSL
already knows how to hook everything together. It's one line in python to use
PKI/TLS as a gemini client:

> context = ssl.create_default_context()

You could argue that PKI is overkill for gemini, and to an extent I agree with
this on a philosophical level. It just happens to be that the way operating
systems and SSL libraries have evolved, you effectively get PKI for "free" from
the perspective a software developer. The same way that I don't need/want to
know how the TCP handshake works at the kernel level, I would rather let the
operating system handle my trust model for me.

- Michael

---

Previous in thread (2 of 15): 🗣️ plugd (plugd (a) thelambdalab.xyz)

Next in thread (4 of 15): 🗣️ solderpunk (solderpunk (a) SDF.ORG)

View entire thread.