I see mandatory TLS or any mandatory crypto scheme as a grey goo problem
that creates limitations and unnecessary complexity and overhead that
will grow like grey goo over time.

Communication protocols should be crypto and cipher-agnostic. The
end-user client and server should decide how to proceed with crypto.
Putting all eggs in one crypto basket is ill-advised.

There are many potential use cases for different crypto schemes or no
crypto at all. Being bound to one crypto scheme hampers and complicates
a lot of potential and imaginative use cases.

I suggest that going forward the protocol definition have a header
instruction that allows negotiation of different crypto schemes, or no
scheme at all.

It is also possible to have schemes that serve digitally signed plain
text over a clear text connection, without an encrypted channel. Such
would be perfectly suited for a public-facing site that is serving only
public text. This provides authenticity without the TLS overhead, and
allows any custom arrangement of ciphering, key exchange, certificate
authority and authentication that servers and clients would desire.

We don't need yet another mandatory cryptosystem in between every
communication in every context.

I propose for your consideration:

Adjust the Gemini protocol with a clear standard requirement that the
protocol itself be cryptography neutral or 'crypto agnostic'.

Adjust the Gemini protocol with a clear standard that the protocol
itself is concerned only with the format and stream between endpoints.

Adjust the Gemini protocol with a clear standard requirement that
decisions regarding encryption, authentication and connection security
be left up to the designers of clients and servers and the endpoint users.

Adjust the Gemini protocol with a clear standard header instruction for
the negotiation, selection, and establishment of cryptographic
primitives, signatures, authentication, or lack thereof.

--

Text Master

YE4RVOOQ46VI47W2TIMT56QEHGIQQM4DNEIRQXU6FXPZX5IV6NTA

Text Master wrote:
>
>
> We don't need yet another mandatory cryptosystem in between every
> communication in every context.
>

Why not use Gopher then?

In my opinion, changing the protocol is a no-go. Gemini is not open to
change!

--
gemini://kwiecien.us/

El lun, 31-10-2022 a las 15:17 -0500, Text Master escribió:
> I see mandatory TLS or any mandatory crypto scheme as a grey goo
> problem
> that creates limitations and unnecessary complexity and overhead that
> will grow like grey goo over time.
>
> Communication protocols should be crypto and cipher-agnostic. The
> end-user client and server should decide how to proceed with crypto.
> Putting all eggs in one crypto basket is ill-advised.
>
> There are many potential use cases for different crypto schemes or no
> crypto at all. Being bound to one crypto scheme hampers and
> complicates
> a lot of potential and imaginative use cases.
>
> I suggest that going forward the protocol definition have a header
> instruction that allows negotiation of different crypto schemes, or
> no
> scheme at all.
>
> It is also possible to have schemes that serve digitally signed plain
> text over a clear text connection, without an encrypted channel. Such
> would be perfectly suited for a public-facing site that is serving
> only
> public text. This provides authenticity without the TLS overhead, and
> allows any custom arrangement of ciphering, key exchange, certificate
> authority and authentication that servers and clients would desire.
>
> We don't need yet another mandatory cryptosystem in between every
> communication in every context.
>
> I propose for your consideration:
>
> Adjust the Gemini protocol with a clear standard requirement that the
> protocol itself be cryptography neutral or 'crypto agnostic'.
>
> Adjust the Gemini protocol with a clear standard that the protocol
> itself is concerned only with the format and stream between
> endpoints.
>
> Adjust the Gemini protocol with a clear standard requirement that
> decisions regarding encryption, authentication and connection
> security
> be left up to the designers of clients and servers and the endpoint
> users.
>
> Adjust the Gemini protocol with a clear standard header instruction
> for
> the negotiation, selection, and establishment of cryptographic
> primitives, signatures, authentication, or lack thereof.
>

There's this protocol already proposed, crypto-agnostic (in fact, it
doesn't mandate any!) and it's very similar to gemini: spartan

Take a look before trying to change what most people like as it is, and
maybe you can build your new, crypto-agnostic protocol!

gemini://spartan.mozz.us/ for more info. I think it will give you the
base for your project... and then you can propose a derivation, if you
want to.

All the best,
Reset Reboot

Text Master <text@mast.er> wrote:
> I see mandatory TLS or any mandatory crypto scheme as a grey goo problem
> that creates limitations and unnecessary complexity and overhead that
> will grow like grey goo over time.
>
> Communication protocols should be crypto and cipher-agnostic. The
> end-user client and server should decide how to proceed with crypto.
> Putting all eggs in one crypto basket is ill-advised.
> There are many potential use cases for different crypto schemes or no
> crypto at all. Being bound to one crypto scheme hampers and complicates
> a lot of potential and imaginative use cases.

I believe this, but see my notes below, for how I think to improve this,
rather than using your proposal.

> I suggest that going forward the protocol definition have a header
> instruction that allows negotiation of different crypto schemes, or no
> scheme at all.
>
> ...
>
> Adjust the Gemini protocol with a clear standard requirement that the
> protocol itself be cryptography neutral or 'crypto agnostic'.

I think that adjusting the protocol is unnecessary. Instead, my proposal is
to define another URI scheme which denotes "Gemini without TLS" (I had
proposed "insecure-gemini" but maybe it is long). The protocol is the same,
except without TLS (and due to the TLS initialization messages not being a
valid URL, it should also be possible to use the same port number). Any
status codes that specify that client certificate is required, are not
allowed (in these cases, it should redirect to the secure service instead;
such a redirect should not occur in any other cases, though).

--
Don't laugh at the moon when it is day time in France.