Until the Misfin protocol is developed (I have found at least three editions), I would like to raise the question about the TLS requirement for all connections.
In short, the main point is described here:
Personally, I'm using encrypted IPv6 mesh networks like Yggdrasil, and I really don't want any external TLS layer. Maybe it's time to care about now than later?)
Jun 26 · 6 months ago · 👍 norayr, tenno-seremel
15 Comments ↓
To give more context, misfin(A) is basically defunct, but was one option for a spec that Lem had, then Lem developed misfin(B) that changed a few things around, and then he went away for about a year, so I, satch, and a few others worked on misfin(C), which is a minimal-ish update that increases message length and makes message metadata more uniform in their format.
So far, all of the misfin(C) servers I know about (including mine) also support misfin(B), and the misfin(C) clients can also talk in misfin(B), so the software for misfin(B) and misfin(C) are effectively interoperable.
Lem came back for like a day or two and said they were going to take parts of misfin(C) and put it into a more official misfin spec, but then they dissappeared again, unfortunately.
I have a really good misfin server, but I haven't worked on it in a long while, so things have gotten stagnant. My own misfin server also went down for a few reasons. But I do want to continue working on misfin at some point in the near future.
Thanks for detailed info. Is your server written in Rust?
I have installed this one to learn the code and test:
I also have an old dream of creating an HTML-free messenger for mesh networks, where everyone can set up their own server for free (over NAT) and use it for communication. Misfin looks promising, but the TLS issue is the only thing stopping me from pursuing this idea.
@ps No, mine's in golang. Here: https://gitlab.com/clseibold/misfin-server
It supports misfin(B) and misfin(C), and has very basic initial GMAP support that works with @satch's Skylab. You can find more info about misfin(C), Skylab, and GMAP here: gemini://satch.xyz/misfin/
My server also supports mailinglists and an alternative to usenix/newsgroups that I was working on, called newsfin. We had a federated misfin mailinglist system working, but my server went down, so now only @satch and one other person's misfin mailinglist are federated. It's pretty cool. Here's the WIP capsule detailing newsfin, but it's very unfinished:
gemini://newsfin.us.to/
I've been so busy that I haven't had the time to bring my misfin server back up, but maybe I will this week! I'll also have to contact satch to setup the federated mailinglist again.
Also, here's a really good guide that someone made for setting up my misfin-server using docker: gemini://capsule.valkyrieshowl.com/gemlog/setting-up-misfin-server-with-docker.gmi
Thanks for the link,
even though I don't understand the code in Go (to learn the protocol details),
I would like to try this server in the production.
@ps I will set up my misfin server tomorrow, and then we can send emails back and forth if you want to try it.
I've done a lot of programming for today, so I'm taking a break, but if you ever have any questions, you can ask them here, or I'll be sure to stay in the ##misfin IRC chat on libera.chat (satch is also in there, although not sure if he's active on it), and I'll get to them tomorrow when I have time.
Well, I recently tested how does it work with myself on the localhost. Now I'm getting my words about TLS back, because I forgot about the user identity part, maybe asymmetric model is really useful here.
@clseibold I plan to run my server using Yggdrasil, do you have one? I don't plan to use internet server as have no dedicated IP (and don't plan to order).
@ps I don't know barely anything about Yggdrasil, but I think I checked it out before and seen that it required IPv6, which I don't have at all (a lot of internet service providers in the US don't provide ipv6 at all).
... but finally, no. If the server manages user profiles, why does it require TLS for identity? This would only be useful if the server is able to receive the message and store it encrypted, but the user, who has the private key, can read it - similar to what is implemented in Tutanota or ProtonMail.
I see no rational reason to require TLS from the user if the server hosts the private keys and also requires name management. If the user maintains their own server address, they already own the mailbox.
@ps I don't know barely anything about Yggdrasil
@clseibold it's literally gives you one more internet interface (like vpn) where you can connect over IPv6 in 0200::/7 range. Also it's written in Go:
I wonder why people are using Gemini but not yet using Yggdrasil :)
@ps I'll check it out to see if I can get it set up. Thanks!
@ps Client certs are used for identity verification when *sending*, not receiving. It allows you to send from *any* device anywhere. It's not that different from having a client cert over gemini to post on BBS, but then BBS sends messages to your special email server when you receive messages (if BBS ever had such a thing). That is effectively what misfin is.
TLS is used to encrypt over the wire. There is no method of encrypting on the server's storage.
You could implement misfin over a different network protocol if you can use x509 client certificates. An example of this would be Quic, which does have a way to use x509 certs, iirc.
Also, you don't want something like nex for misfin - otherwise it would send messages over tcp directly in plaintext, which is prone to man-in-the-middle-attacks, and people can snoop your messages, which is not a thing you generally want. You want some form of encryption, with x509 certs, in whichever low-level protocol allows for this (Tor? Quic, TLS, etc.)
And just to be clear, misfin is not exactly like email. When you send a misfin mail to someone, you send it *directly* to their server, not to your server that then routes to their server. That's why the client certs are a thing.
@clseibold, in my case, there is no one in the middle because I'm using an encrypted tunnel interface, but I still MUST use TLS to interact with the destination, which is already owned by the recipient.
@ps Right, that's because the protocol doesn't specify anything for tunnels that already have encrption. With quic, you can use x509 certs in quic itself, and so the protocol doesn't need to specify anything really to work over quic. But if we're dealing with tunnels or other encryption methods, then the spec would have to specify how x509 client certs are dealt with.
It's just easier to define your protocol to work over TLS or Quic, or other wire protocols that use x509 certs, though.
Btw, a lot of people are generally overestimating the weight of TLS 1.3 and Quic, imo. They are both very lightweight, afaik.
@ps Also, here's a page about why Tor sites would still use HTTPS instead of just HTTP: https://onionservices.torproject.org/research/proposals/usability/certificates/
A lot of this also pretty much applies to other networks, like i2p and yggdrasil, imo.
@ps One more thing. In misfin, mailbox certificates actually don't need to be stored on the misfin server. You can crate a certificate signing request (CSR) to the misfin server on mailbox creation, and the private key of the mailbox cert never has to leave a person's local computer.
Nobody does it this way *because* there's no GUI misfin clients, lmao. So our "misfin clients" are implemented on the misfin server atm using a Gemini client (basically the equivalent of webmail, but for Gemini; e.g., skylab, or in my misfin-server, or @gemalaya's misfin server). These "Geminimail" misfin clients have to be able to send using a mailbox's private key, and so that's the only reason you would store your misfin mailbox private key on a misfin server.
Hopefully this makes sense.