💾 Archived View for gemi.dev › gemini-mailing-list › 000271.gmi captured on 2024-06-16 at 12:50:48. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Unpopular opinion time: Gemini should not have mandatory TLS. - TLS is not conveinent for local development - TLS is inherently dependent on a centralized oligarchy of CAs - Baking TLS into the protocol is going to be a bad look when The Next TLS comes out - Some alternative modes of internet access have built-in encryption guarantees: yggdrasil, cjdns, Tor; and for these adding TLS is redundant (and arguably worse)
Hey Drew, > Unpopular opinion time: Gemini should not have mandatory TLS. We already had the discussion. Please see the ML-Thread on "Mercury", especially solderpunks answers there. See here: gemini://rawtext.club/~sloum/geminilist/001927.gmi I think a lot of people on the list here are tired of seeing the same mail thread appearing again and again Regards - xq
Hello! I'm in favour of mandatory TLS for Gemini, so let me take a stab at this. > - TLS is not conveinent for local development > - TLS is inherently dependent on a centralized oligarchy of CAs I think you've misunderstood how TLS works in Gemini. Gemini works using TOFU, or Trust On First Use, which means that CAs are out of the picture, and self-signed certs can be (and are) used. Generating a self-signed cert is pretty simple for local dev. You can learn more about this in the Gemini spec, and also I've just written a post about how TOFU works in Gemini: gemini://makeworld.gq/gemlog/2020-07-03-tofu-rec.gmi > - Baking TLS into the protocol is going to be a bad look when The Next > TLS comes out > - Some alternative modes of internet access have built-in encryption > guarantees: yggdrasil, cjdns, Tor; and for these adding TLS is > redundant (and arguably worse) Solderpunk has addressed these concerns on the list before, where he's said that Gemini was created for the here and now, for the modern, current, internet. I am involved in the meshnet community, and am all for them succeeding, and yes, TLS would be an overhead. But right now that is not the situation for the majority of people, and Gemini is designed to work and be (somewhat) secure *today*. Cheers, makeworld
On Sat, Jul 04, 2020 at 09:44:16AM -0400, Drew DeVault wrote: > Unpopular opinion time: Gemini should not have mandatory TLS. To be honest, I think by now this counts as a pretty popular opinion. :) > - TLS is not conveinent for local development Mostly because the `openssl` tool for making certs is garbage? I do hope to write a simple replacement for it for Gemini purposes soon. > - TLS is inherently dependent on a centralized oligarchy of CAs I don't think the dependency is inherent, and have tried to push back against it by explicitly speccing TOFU as a first-class option. I admit this has proven to conflict much harder than I expected with the "simplicity of implementation" idea as it turns out most TLS libraries are not designed to do anything remotely unorthodox, which is a real shame. > - Baking TLS into the protocol is going to be a bad look when The Next > TLS comes out > - Some alternative modes of internet access have built-in encryption > guarantees: yggdrasil, cjdns, Tor; and for these adding TLS is > redundant (and arguably worse) I can see the merit of these arguments. In the context of a protocol designed for use into the long term future and by people who are technically skilled enough that they can set up something like Yggdrasil, building in TLS is indeed dubious. But I'm not targetting that space with Gemini. There is no shortage of (good!) projects offering ways to distribute content online which is more private, more decentralised, and more censorship resilient than Gemini. They all come with substantial "cognitive friction" in the form of concepts that many developers and most users don't, won't or can't understand, and as such they have all remained small projects and there's a good chance they always will. Gemini is by design "radically familiar" and people don't have to learn any new concepts to build for it or use it. I believe this is a large part of the reason why Gemini already has a ridiculous number of implementations and a surprising number of hosts. While it hasn't yet been codified as an official goal of the project, I at least have increasingly come to conceptualise Gemini as a "lifeboat for evacuees from the web", and specifically "a better lifeboat than Gopher", which a lot of people won't jump to precisely on account of its total lack of security. Gemini lets something like "ordinary people" shift their content off the web onto something vaguely weblike without having to learn any weird new concepts or do anything strange to their computer. This is a valuable thing to have and not a space which has received much exploration. Removing mandatory TLS would make Gemini a much worse lifeboat here and now and I'm reluctant to do this for the sake of making Gemini a more viable option in a hypothetical future where everybody is on something like Yggdrasil. Cheers, Solderpunk
It was thus said that the Great Drew DeVault once stated: > Unpopular opinion time: Gemini should not have mandatory TLS. > > - TLS is not conveinent for local development > - TLS is inherently dependent on a centralized oligarchy of CAs > - Baking TLS into the protocol is going to be a bad look when The Next > TLS comes out > - Some alternative modes of internet access have built-in encryption > guarantees: yggdrasil, cjdns, Tor; and for these adding TLS is > redundant (and arguably worse) I won't argue that TLS is a bad choice, but before throwing out alternatives like yggdrasil, cjdns or noise, instead *just implement the damn thing* [1][2]---write both a Gemini server and client (for bonus points---implement ALL THE ENCRYPTIONS!) so the rest of us can see how easy it is, and *then* we can have an actual discussion about transitioning away from TLS (or including other mechanisms). This has already been done once: gemini://gemi.dev/gemini-mailing-list/messages/000457.gmi and the follow-up: > #### About my previous proposal > > I'll have to think harder about it (within my limited cryptographic > expertise), and perhaps submit it to a cryptographers community for > feedback. > > At the moment I can see only a minor privacy flaw in it: the client > discloses its identity (and proof of identity) to any server; instead > it should first wait for the server to disclose its identity (and > proof of identity) before proceeding. > > This issue stems from the fact that the ransport_prepare function > is "symmetrical" and tries to reduce network round-trips; instead the > client could first wait for the server verifier and then send its own > (i.e. just a minor change to that function). (gemini://gemi.dev/gemini-mailing-list/messages/000477.gmi) -spc (Note: not much from Ciprian since then ... ) [1] I disagreed with solderpunk about the status codes when he first proposed Gemini. In stead of hashing it out over months, I just went ahead and wrote a Gemini server with the status codes I thought it should have. We then spent a few months hashing it out, but at least there was an implementation (or two by the time the discussion came to an end) backing up the argument(s). [2] This applies to anyone, not just Drew.
On Sat, Jul 04, 2020 at 05:12:17PM -0400, Sean Conner wrote: > I won't argue that TLS is a bad choice, but before throwing out > alternatives like yggdrasil, cjdns or noise, instead *just implement the > damn thing* [1][2]---write both a Gemini server and client (for bonus > points---implement ALL THE ENCRYPTIONS!) so the rest of us can see how easy > it is, and *then* we can have an actual discussion about transitioning away > from TLS (or including other mechanisms). I don't really know much about cjdns or noise, but Yggdrasil just looks like an ordinary IPv6 tunnel and requires nothing special from software. There is actually already at least one Gemini server on the public Yggdrasil network. The admin is also an AV-98 user and I assume he's using it without any modification. I plan to experiment with this myself, someday... Cheers, Solderpunk
It was thus said that the Great solderpunk once stated: > On Sat, Jul 04, 2020 at 05:12:17PM -0400, Sean Conner wrote: > > > I won't argue that TLS is a bad choice, but before throwing out > > alternatives like yggdrasil, cjdns or noise, instead *just implement the > > damn thing* [1][2]---write both a Gemini server and client (for bonus > > points---implement ALL THE ENCRYPTIONS!) so the rest of us can see how easy > > it is, and *then* we can have an actual discussion about transitioning away > > from TLS (or including other mechanisms). > > I don't really know much about cjdns or noise, but Yggdrasil just looks > like an ordinary IPv6 tunnel and requires nothing special from software. If that's the case for Yggdrasil, then you are *still* using TLS over it (and it's not a replacement for TLS). -spc
On Sat, Jul 04, 2020 at 05:56:19PM -0400, Sean Conner wrote: > > I don't really know much about cjdns or noise, but Yggdrasil just looks > > like an ordinary IPv6 tunnel and requires nothing special from software. > > If that's the case for Yggdrasil, then you are *still* using TLS over it > (and it's not a replacement for TLS). You're right, it's not a replacement - running Gemini without TLS over Yggdrasil would break any client certificate apps. No alternative is going to keep those working. TLS is baked in pretty deep. Cheers, Solderpunk
On 04.07.20 23:59, solderpunk wrote: > TLS is baked in pretty deep. Someone who implements Gemini over <TLS_alternative> could if that alternative didn't offer anything that can be a drop in replacement for client certificates do a negotiation protocol before doing the usual Gemini request. That negotiation would probably look something like this: server sends some data. (That could also be the servers public key and a payload that verifys the servers identity) client signs it and reply's with the signature and its public key or a well known placeholder that means "no certificate" (I not even spend two minutes of thinking on this, so don't assume this is THE way to do it) What I want to say is that while not easy it also isn't impossible to replace TLS. (If that someone wrote a good library for this in C (or at least with a c API) it could be bound to most languages people are already writing Gemini software in (the replacement crypto library has to be ported and clients and servers be extended to handle the new underlying protocol anyway). Just throwing the idea out there, have a nice Evening! - Baschdel
---