💾 Archived View for rawtext.club › ~sloum › geminilist › 006321.gmi captured on 2023-11-14 at 09:27:36. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

-=-=-=-=-=-=-

<-- back to the mailing list

[spec] A possible client-side, community-based solution to the drawbacks of TOFU authentication

Benjamin Cronin bcronin720 at gmail.com

Sun Apr 11 09:12:30 BST 2021

- - - - - - - - - - - - - - - - - - - 

There are several issues with Gemini's utilization of TOFU that I believecan be solved using a system of a distributed certificate authority.

The reasoning for having an extra step of security past TOFU is that uponfirst connection, the user does not know whether or not the certificatethey receive is legitimate or malicious. TOFU always trusts the firstcertificate it receives without knowledge of whether or not the host isactually who they claim to be. Therefore, my proposition to mitigate thisis to set up a distributed network of nodes that will act as acommunity-run CA/PKI.

In essence, this distributed trust network (as I'm calling it) acts as acertificate authority which sites will register with to provide clients away to ensure that the certificate they receive from a site when connectingis legitimate, acting as a precursor to TOFU's initial trust. This operatesas a solely client-side process, with the only sysadmin's interaction beingan initial registration and certificate updates, so it does not require anychanges to the actual Gemini protocol. As TLS certificates are used bydefault in the Gemini protocol, it makes sense for a server's long-termcertificate to be registered in a public place for new visitors of a siteto check against.

I have put a lot of thought and effort into ensuring that a network thatwould provide this service is resilient to malicious attacks whilemaintaining a low power consumption requirement, allowing it to run as abackground process on a home server. This means no blockchain basedtechnology or other popular distributed system of trust, due to thecomputing requirements that their proof of stake require. The network willconstantly check to make sure its peers are acting properly, and willcommunicate any anomalies to the rest of the network.

This may be compared in a slight way to a DHT, but I believe that it isfundamentally different in its operation, as it is built to provide not alookup, but a true CA service.

At the current moment, I have not found any specific research along theselines, so I am unsure of how original this idea is, and if there hasalready been a body of work created that I've missed. I can drawsimilarities to this from existing public key infrastructure, but I'm notentirely convinced that they're the same. I'd welcome feedback on this, andI am working hard to get a larger paper written up on it.

Please let me know your thoughts!- Entflammen-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210411/3fd12014/attachment-0001.htm>