💾 Archived View for gemini.bunburya.eu › newsgroups › gemini › messages › 1667668281.bystand@zzo38co… captured on 2023-01-29 at 03:10:13. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
From: news@zzo38computer.org.invalid
Subject: Re: Gemini Cryptography Protocol Proposal
Date: Sat, 05 Nov 2022 10:17:24 -0700
Message-ID: <1667668281.bystand@zzo38computer.org>
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.
Parent: