πŸ’Ύ Archived View for gemi.dev β€Ί gemini-mailing-list β€Ί 000271.gmi captured on 2023-12-28 at 15:44:22. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-11-04)

🚧 View Differences

-=-=-=-=-=-=-

Ditching mandatory TLS

1. Drew DeVault (sir (a) cmpwn.com)

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)

Link to individual message.

2. Felix Queißner (felix (a) masterq32.de)

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

Link to individual message.

3. colecmac (a) protonmail.com (colecmac (a) protonmail.com)

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

Link to individual message.

4. solderpunk (solderpunk (a) SDF.ORG)

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

Link to individual message.

5. Sean Conner (sean (a) conman.org)

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.

Link to individual message.

6. solderpunk (solderpunk (a) SDF.ORG)

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

Link to individual message.

7. Sean Conner (sean (a) conman.org)

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

Link to individual message.

8. solderpunk (solderpunk (a) SDF.ORG)

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

Link to individual message.

9. Baschdel (baschdel (a) disroot.org)

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

Link to individual message.

---

Previous Thread: GUS, backlinks, and Replies in Geminispace

Next Thread: URL/META length