Re: QUIC (mostly) on top of OpenSSL without patches

[Willy Tarreau <[e-mail]>]

Hi,

On Thu, Jul 06, 2023 at 08:49:49AM -0700, Watson Ladd wrote:
> I think this patch is bad for the ecosystem. We're essentially saying
> there is no alternative to OpenSSL and capitulating to bad
> stewardship, and further deepening the dependency. This means the
> Foundation doesn't have to listen to the community and lets them make
> choices that deepen that dependency.

That's in part why I wanted to open a discussion about this. I think
I have never hidden my feelings about how the things are "managed"
overthere, where users needs and contributors work are totally
ignored without even justifications. We're talking to robots.

> Instead I'd like to have seen
> more energy go into using forks that carry the QUIC patches we want,

We do actively use and encourage to use QuicTLS, we've even documented
how to use it and some of our users have been using this for a year
now. We've also worked closely with the wolfSSL team to make sure
their product works well with haproxy in order to provide an alternate
solution and are still working with them and linux distros to see how
to make it adoptable in a correct state for a few projects.

But an opensource ecosystem doesn't evolve from a few isolated users'
intents and actions only, especially with security components which
experience a lot of resistance to change by definition. At our level
we're doing a lot to present alternatives to our users and to try to
make new ones emerge, but I'm well aware that it will not be sufficient.

In the mean time the situation remains the same, the vast majority of
our users cannot use QUIC because they do not have the skills, the
time, the willingness to rebuild their own libs and watch for security
alerts to update them in time. That's exactly where I think the patch
can help. Am I happy with it ? Not at all, for me it's a collective
failure for not having managed to convince the OpenSSL team to listen
to us. And believe me, offering them this present like this irritates
me to a point you don't imagine. But there are also our users at the
end of the chain, and once a technical solution is on the table, it
wouldn't be fair to keep them hostage just for the sake of repeating
"no it cannot work with openssl, change your lib".

> and a long term goal of replacing OpenSSL with a more modern, well
> designed solution. OpenSSL 3.0's modularity is welcome, but they
> managed to make the wrong choices in so many places, when the right
> ones were there for the taking.

Put it simply, for a number of our users it's simply not usable *at all*
due to the extreme performance regressions coming with this unneeded
modularity. So a number of users will stick to LTS distros that continue
to maintain 1.1.1 past its EOL because they cannot afford to multiply
their number of servers by 10. I know that Rich and Nick are watching
the performance regressions closely as well because that obviously also
affects QuicTLS 3.0, but a huge effort is needed on this area to undo
a lot of the stuff that was done between 1.1.1 and 3.0.0. The OpenSSL
project really seems to be in a dead end for me, it's incompatible with
QUIC and unfixable performance-wise. So yes, alternatives are needed,
but alternatives will still take many years to come and during this
time a lot of users not concerned by performance cannot test QUIC at
all. This also means that it limits the exposure of our various
implementations and that interoperability issues will continue to come
slowly.

> Ultimately this is between application developers, operating systems
> (who decide what libraries will be system ones),

Even operating systems don't completely decide on their own. They need
some assurance that upstream will be maintained long enough and will
help them in case of trouble. That's not always granted with all libs,
and reduces their available choice.

> the US government
> (whose FIPS process is part of the reason OS's make the decisions they
> do),

If at the end of the day the US is the only country in the world having
to continue to bear openssl for eating their own dog food while the rest
of the world has already turned that page, it's likely that something
will change, either FIPS arriving in alternatives, the govt revisiting
their requirements based on technical advice this time, or openssl
restarting from an old working version and merging QUIC. So I'm not
concerned with that one at all.

> and the makers of alternatives. Finally there's the question of
> should we be writing C taking things from the network in the year
> 2023.

This is totally off-topic, I don't want to enter the language rants of
"should you trust the developer or the compiler", especially given that
virtually every network component that participates to our present
discussion is written using this language and has participated to grow
the internet to what it is now. The whole problem OpenSSL is suffering
from is absolutely not technical nor related to a language, but purely
organisational: some people apparently decide by voting in committee
of major changes (and rejections) with zero consideration for their
users' needs, and unsurprisingly it causes a huge havoc because these
users are essentially left with no choice at all at some point. I'm
well aware of the lack of consideration for this approach within the
IETF, I used to have it written on one t-shirt for many years :-)

So to wrap up, yes I'm well aware that going into that direction that
consists in offering a subset of QUIC based on OpenSSL, we're partially
giving up the battle on the OpenSSL front and that does not please me
at all. But as a compensation it can participate to expose QUIC a lot
more, and this trade-off seems positive to me. The remaining question
for this WG is whether we think that this limited QUIC implementation
can hurt QUIC more than it would help it (and note that NGINX already
uses it, I don't know with which success BTW). I tend to think it
would help more but I may be biased and that's why I'm collecting
advices and opinions.

Thanks!
Willy