💾 Archived View for bbs.geminispace.org › s › misfin › 656 captured on 2023-06-16 at 17:34:08. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
Misfin is a nice idea, but I'm worried that it doesn't make sense to replace email with something lacking end-to-end encryption. A server on a multi-user system gets the plaintext of messages to its users. It's fine if you run the server on your own home server, but I guess that wouldn't be the typical configuration.
I wonder if it would be feasible to work in a PGP-like mechanism using the same client key as in the client certificate...
Some other little thoughts after reading through the spec:
I'd recommend mandating TLS 1.3 or greater. In 1.2, client certificates are sent unencrypted, which is a real privacy problem (an eavesdropper finds out exactly who is sending the mail).
To avoid all the headaches we ended up with in Gemini, I'd recommend including something in the spec about how TOFU should handle certificate expiration. Simplest is just to say that self-signed certificates shouldn't expire (Not After set to 99991231235959Z).
2023-05-21 · 4 weeks ago · 👍 satch, lem, jeang3nie
End to end encryption is always an option for clients to implement, no?
It would be pretty limiting to make encryption mandatory. Not everyone needs everything encrypted all of the time, and using a public key/private key system creates a lot of hassle when using multiple devices, etc. Doesn't to me seem like it belongs in the spec.
I like the idea of bumping tls to 1.3 or greater. The only reason I can see for supporting older versions is legacy implementations, for which there should be none with a brand new protocol.
2023-05-22 · 4 weeks ago
@jeang3nie - true, true. Gotta check to see what some of the embedded libraries support but will consider this.
2023-05-24 · 3 weeks ago
@mbays - I'll make a note about TOFU in the spec this week - I was leaning towards certificates not expiring already, glad to hear someone agrees.
In terms of end-to-end encryption, it's probably out of scope for the Misfin spec? As I was envisioning it, people would be primarily hosting their own Misfin servers, so storing the messages encrypted is unnecessary. I'd be down to experiment though - maybe a client that encrypts the message with the receiver's cert?
@lem embedded is a good point. It would be cool to see a misfin server running on a pico or esp32!
@lem But if the assumed mimetype is text/gemini, encrypted messages could only be implemented through a horrible hack, right?
If it's intended that users run their own servers, then there's no problem of course. But then having multiple mailboxes on a given server seems like unnecessary complexity?
Even the most minimal system with end-to-end encryption would be quite a bit more complicated than misfin, it's true. Still, I'm uneasy about accepting transport-only encryption as good enough for a new email-like protocol.
@mbays Depends on what you find to be a horrible hack - a PGP encrypted message could be sent as text/gemini very simply using a preformatted text block. To me, that's not bad.
@satch I almost mentioned that one could just use pgp the same way it's done in regular email. Then I remembered how much pgp sucks.
IMHO end-to-end encryption hasn't been implemented in a genuinely easy way anywhere. It always comes at a price. Clients can try to hide it from users, but it still has costs.
So I guess my question is, what implementation of end-to-end encryption sucks less than PGP? What would that look like for Misfin?
Sending unencrypted messages to a server is usually OK for most people, especially for the purposes of the small web (the target userbase of Misfin). A Misfin client which makes PGP-style encryption easy is totally doable. Once you start introducing multiple devices, e2e will get annoying no matter what protocol is being used.
Any way you encrypt it, the receiver must have the key to decrypt it. So the question becomes, how do you get the key to the receiver without sending it the the server first? It's the proverbial chicken and egg proglem. Pgp may suck, but it at least is a solution. Unless someone has a really actually nice solution I can't see making it a required part of the spec.