💾 Archived View for gem.benscraft.info › mailing-list › messages › 191 captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
drawbacks of TOFU authentication
- Benjamin Cronin <bcronin720 at gmail.com>
@ Sun, 11 Apr 2021 04:12 -0400
────────────────────────────────────────────────────────────────────────────────
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
════════════════════════════════════════════════════════════════════════════════