💾 Archived View for gemi.dev › gemini-mailing-list › 000863.gmi captured on 2024-08-31 at 18:43:57. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
There are several issues with Gemini's utilization of TOFU that I believe can be solved using a system of a distributed certificate authority. The reasoning for having an extra step of security past TOFU is that upon first connection, the user does not know whether or not the certificate they receive is legitimate or malicious. TOFU always trusts the first certificate it receives without knowledge of whether or not the host is actually who they claim to be. Therefore, my proposition to mitigate this is to set up a distributed network of nodes that will act as a community-run CA/PKI. In essence, this distributed trust network (as I'm calling it) acts as a certificate authority which sites will register with to provide clients a way to ensure that the certificate they receive from a site when connecting is legitimate, acting as a precursor to TOFU's initial trust. This operates as a solely client-side process, with the only sysadmin's interaction being an initial registration and certificate updates, so it does not require any changes to the actual Gemini protocol. As TLS certificates are used by default in the Gemini protocol, it makes sense for a server's long-term certificate to be registered in a public place for new visitors of a site to check against. I have put a lot of thought and effort into ensuring that a network that would provide this service is resilient to malicious attacks while maintaining a low power consumption requirement, allowing it to run as a background process on a home server. This means no blockchain based technology or other popular distributed system of trust, due to the computing requirements that their proof of stake require. The network will constantly check to make sure its peers are acting properly, and will communicate any anomalies to the rest of the network. This may be compared in a slight way to a DHT, but I believe that it is fundamentally different in its operation, as it is built to provide not a lookup, but a true CA service. At the current moment, I have not found any specific research along these lines, so I am unsure of how original this idea is, and if there has already been a body of work created that I've missed. I can draw similarities to this from existing public key infrastructure, but I'm not entirely convinced that they're the same. I'd welcome feedback on this, and I am working hard to get a larger paper written up on it. Please let me know your thoughts! - Entflammen
On Sun, Apr 11, 2021 at 04:12:30AM -0400, Benjamin Cronin <bcronin720@gmail.com> wrote a message of 89 lines which said: > a server's long-term certificate to be registered in a public place > for new visitors of a site to check against. The main issue with your proposal is "who will check that this registration is done by the rightful [for some definition of rightful] holder, and how will they do this check?" Instead of saying: > I have put a lot of thought and effort I suggest that it would be better to give the answer to the above issue. I do not find in your email even one line of technical explanation about your invention. > This means no blockchain based technology or other popular > distributed system of trust, due to the computing requirements that > their proof of stake require. You mean proof of work? Because proof of stake does not have such computing requirments. Anyway, even blockchains, as demonstrated in the last ten years with Namecoin, still have the problem of initial enrollment. How do you address it? [Namecoin is strictly first-come-first-served, with zero recourse in case something goes wrong.] > At the current moment, I have not found any specific research along > these lines, Without specific requirments, it is hard to say if there is something similar. For instance, do you plan to do something similar to Certificate Transparency, or will you envision something different? Other relevant stuff may include CoDoNS <http://www.cs.cornell.edu/people/egs/beehive/codons.php> ConfiDNS <https://www.usenix.org/legacy/event/worlds06/tech/prelim_papers/poole/poole_html/> ENS <https://ens.domains/> or the many others "distributed trust" systems now buried under 404 error codes. Sorry if I'm harsh but, as you know "I have designed a secure, efficient, cheap system of distributed trust and naming over the Internet" is in computer networks what the "I have deciphered the Phaistos disk" is in linguistics. We are cautious.
---
Previous Thread: [spec] The security model for TLS is also discussed inside IETF