Regarding `gemini://` over NaCL (replacing TLS)

• 🗣️ From: Ciprian Dorin Craciun (ciprian.craciun (a) gmail.com)
• 📅 Sent: 2020-03-02 13:23
• 📧 Message 6 of 18

On Mon, Mar 2, 2020 at 10:36 AM Bradley D. Thornton
<Bradley at northtech.us> wrote:
> Question: Isn't it (even if non-trivial) possible, to account for other
> methods of encryption by the listening daemon, some servers being able
> to secure communications by one or another method if the upcoming
> clients can also support those technologies?


This is exactly what happened with SSL (at least two versions) which
coexisted alongside with TLSv1.0, which then together coexisted
alongside with TLSv1.1, which then all together coexisted with
TLSv1.2, which now all coexist with TLSv1.3;  and although everybody
screams that anything under TLSv1.2 is "broken", we still haven't
dropped support for TLSv1.1...  :)

My take is having "options" is good for "complex" things, however for
simple things, like `gemini://` strives to be, having one "good-enough
but simple" solution is the best.


So if I were to vote I would say:

	
let's add the notion of "`gemini://` protocol version" that the

client sends in the first packet (even before encryption), and the
server must match or error out;  (we need to make sure that after the
encryption is established, this "version" is re-confirmed, so that we
aren't vulnerable to protocol downgrade attacks;)

	
let's push the community to keep compatibility with no more than 3

`gemini://` protocol versions;  (i.e. the current "stable", the
previous "stable", and the "long-term-support" one;)

Ciprian.

---

Previous in thread (5 of 18): 🗣️ Ciprian Dorin Craciun (ciprian.craciun (a) gmail.com)

Next in thread (7 of 18): 🗣️ Sean Conner (sean (a) conman.org)

View entire thread.