💾 Archived View for gem.benscraft.info › mailing-list › threads › 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
In reply to
────────────────────────────────────────────────────────────────────────────────
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
════════════════════════════════════════════════════════════════════════════════
drawbacks of TOFU authentication
- Stephane Bortzmeyer <stephane at sources.org>
@ Sun, 11 Apr 2021 11:17 +0200
In reply to Benjamin Cronin <bcronin720 at gmail.com>
────────────────────────────────────────────────────────────────────────────────
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.
════════════════════════════════════════════════════════════════════════════════