Comment by 🦂 zzo38

=> Re: "Enhancing Gemini’s TOFU Model with Convergence: A Proposal..." | In: s/Gemini

I also had a idea for decentralized validation, where anyone could sign anyone else's certificate; a DER file could be available by any protocol (TLS is not needed, although it is OK if you have it) or disk, which lists with certificates you approve and the details of the approval, including which extensions of the certificate you understand and which you don't, and what details you trust (e.g. the Common Name). It could also be used with what you describe. I wrote on a paper about the schema, and I will mention it here later when I write it on the computer.

Additionally, I also had a idea about superseding self-signed X.509 certificates. This is currently mentioned in the Scorpion protocol specification (in the section about X.509 extensions), but I think there might be a problem with it. I will post a separate message with my comments about how it is now and what I think it might be changed to.

=> — Superseding X.509 certificates

=> 🦂 zzo38

2024-11-05 · 3 months ago

7 Later Comments ↓

=> 🦋 CarloMonte · Nov 05 at 06:54:

Please don't resurrect GPG. Joke apart, the proposed scheme lacks transparency and simplicity, which Gemini explicitely promotes at the expense of security.

=> 👻 mediocregopher [...] · Nov 05 at 07:21:

All "problems" with TOFU can be solved with DANE. It would require no changes to Gemini servers or their certificates at all, and can be an optional check performed by clients. It relies on existing infrastructure (DNS, DNSSEC), and is already a standard with many different implementations existing and wide-usage as a security mechanism for email.

There's no need to introduce something new. I'm not even sure there's need to introduce something at all; TOFU works fine for gemini, it's not like we're doing our banking here.

=> 👺 daruma · Nov 05 at 07:22:

Are there really users out there that want more secure Gemini? Or is this just a tech/programmer desire to expand the protocol? I think the idea of security also depends on the use case of a technology; if I use technology for the fun of it, why would it need to be secure? For me Gemini is enjoyable because it doesn't need to be secure, there aren't countless password, 2fa, captcha etc..

=> 🐑 zeerooth · Nov 05 at 08:44:

I agree with @mediocregopher - we already have DANE, which is decentralized as well, and actually already a part of gemini spec as a recommendation for clients as an additional security measure for validating certificates.

=> 🚀 mbays · Nov 05 at 22:18:

Is there a spec for this Convergence scheme? From the information in the links, I expect that it's too complicated to have a chance of being adopted by gemini developers (and the same probably goes even for the simplest notary schemes).

=> 🚀 mbays · Nov 05 at 22:18:

I did find Moxie's criticisms of DANE in the second link interesting, by the way.

=> ☕️ tenno-seremel · Nov 06 at 07:28:

@daruma Because otherwise an ISP can MitM you and censor or add any data (which you’d think comes from someone else’s mouth), or feed your system a 0-day exploit to monitor you better. Although I don’t think the thing that OP suggests is a solution I’d want.

Original Post

=> 🌒 s/Gemini

Enhancing Gemini’s TOFU Model with Convergence: A Proposal for Decentralized, Collaborative Certificate Validation — The Gemini protocol’s minimalist, privacy-focused design is a refreshing alternative to the traditional, often bloated web. Its reliance on Trust on First Use (TOFU) brings much-needed decentralization and reduces dependence on Certificate Authorities (CAs). However, as Daniel Stenberg and others have pointed out, TOFU has inherent vulnerabilities. Specifically, it requires users...

=> 💬 LooseCannon · 8 comments · 1 like · 2024-11-04 · 3 months ago

Proxy Information
Original URL
gemini://bbs.geminispace.org/u/zzo38/21545
Status Code
Success (20)
Meta
text/gemini; charset=utf-8
Capsule Response Time
57.108682 milliseconds
Gemini-to-HTML Time
0.778473 milliseconds

This content has been proxied by September (3851b).