Hi Kevin, hi.

Kevin Chadwick via Dng - 27.09.24, 14:09:45 CEST:
> On 26/09/2024 23:24, Martin Steigerwald wrote:
> > On the other hand even the OpenSSL related report from a LibreSSL
> > developer did not really take into account overworked developers and
> > maintainers. While I laughed on some of the very dire programming
> > mistakes elaborated in that report… I meanwhile see both sides of the
> > story and wonder how many developers work on cups-browsed. However it
> > appears to me the report by Simone Margaritelli can make for a good
> > laugh as well as it also seems to be formulated in a somewhat
> > sarcastically toned humorous way.
>
> If OpenSSL took a more conservative approach like BoringSSL or LibreSSL
> then the maintainer may not have been overworked. If you think the
> problems of OpenSSL have been fixed since then after the Linux
> foundation throwing money at the wrong project. You are wrong. They
> keep getting more CVEs than OpenSSL and causing more in users
> applications. The Gentoo article on the subject was and likely still is
> very misleading.

Okay, fair point, Kevin. I agree to that. Thank you for your perspective.

It was too complex to begin with.

And, for example, reading outside of own memory boundaries to work around
sub optimal random number generators in operating systems was never a good
idea to begin with.

> The OpenBSD devs aren't going to spare the time to write from scratch
> but it would be simpler still if they did. Even better would be writing
> it in a language like Ada or Rust. Perhaps once TLS1.2 is deprecated
> and only supporting the simpler TLS1.3 and PQC is required.

Actually whenever I have to deal with TLS and TLS certificates I like to
run away. Even the protocol and maintaining certificates itself is insanely
complex. In curses I hold, like for example log file analysis, I usually go
with demo setups, like for OpenSearch. Cause going through generating
proper certificates manually and explaining how all of that works would
easily add half a day just for that. Initiatives like Let's Encrypt
mitigate some of that, but in a less than optimal and still centrally
managed way.

However I did not look into how and to what extent TLS 1.3 and PQC are
simpler than TLS 1.2.

And I do not really agree to top-down centrally managed trust
relationships.

But redoing it from scratch also has a risk:

How standards proliferate

https://xkcd.com/927/

While a lot of Internet standards aged way better than I probably would
have anticipated if I had been witnessing their introduction as an adult
human being… with today's knowledge it might be possible to remove a lot
of cruft and complexity. But it would basically a completely new protocol
stack which, in order to achieve the simplification would be incompatible
from what is in use today.

I still admire Amiga Envoy local networking software. They bolted their
own protocol directly on the IP layer by using a different IP type. When
copying files to a network drive while someone disconnects the Ethernet
cable it immediately came up with a dialog window "please insert drive
NAME again". And if you plugged the cable in again within seconds it
resumed the transfer. Mind you, that software is from the 90-ties of last
century. However the software does not encrypt any data to begin with. But
still it is an example for simplicity and usability.

Best,
--
Martin