Request for feedback from server/client implementers using\n non-OpenSSL TLS stacks

[Drew DeVault]

Off the bat, I'm not so sure that gmnisrv or gmni really is all that
popular. I use it myself, and I know several other who also use it, but
I suspect that we are in the minority. To be honest, it's not even that
great, it crashes fairly often and is pretty unreliable as a result. The
main appeal is that it is simple and has few dependencies, which are
traits that BearSSL directly contributes to.

Another goal of gmnisrv is to be easy to maintain and reliable over the
long-term, which is something that BearSSL offers and something that
pinning ourselves to bleeding-edge technology witholds. I am very busy
and I don't have the time to invest in, for example, overhauling the SSL
stack for my Gemini software. Gemini is designed to be simple to
implement, and my hope is that it is also simple to maintain.

The advantages of TLS 1.3 are fairly trivial in my opinion. Encrypting
the client hello is nice (though, as you pointed out, not broadly
supported), but what you call "grassroots CDNs" is just another word for
centralization - these are in conflict, and I tend to cast my lot with
decentralized governance more so than ideal privacy. This is fixing it
at the wrong level, anyway - overlay networks like yggdrasil or Tor
actually obsfucate who you're talking to properly (and provide transport
encryption, which is why I would have liked to see optional TLS for
Gemini under certain circumstances...).

As for the other two changes you mentioned: Padding is an improvement.
Performance is not important.

In short, the benefits are marginal, using BearSSL provides us with
greater advantages than disadvantages, and BearSSL better serves the
project's goals. What's more, I don't think I can easily spare the time
to make the necessary changes myself, and these projects are explicitly
designed to be low-maintenance. I can hardly find time for the
improvements I *want* to make, like automatic cert generation based on
Michael Forney's x509 library.

That said, if someone does feel strongly enough about this to put in the
work, I would be willing to accept patches which address the problem. I
very much do not want to use LibTLS, but maybe mbedTLS is a good option.
Any patch would have to provide justification that the alternate TLS
stack is simple, robust, and will be easily maintained in the long term
(and, for what it's worth, OpenSSL is not any of these!).

Also, in the long term, I plan on writing a Gemini stack in my new
programming language, which will probably make gmnisrv and gmni
obsolete. However, we have to make our own crypto stack from scratch
first, so I wouldn't expect to see that any time soon.