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

[Ryan Hamilton <[e-mail]>]

I agree with Watson. There are plenty of alternative TLS libraries out
there which support complete QUIC functionality. I work on Chrome and
Envoy, which both use BoringSSL successfully, for example. My experience
with QUIC performance on the web suggests that 0-RTT is critical for making
QUIC perform as well as it does. I would hate to see 0-RTT-less QUIC used
widely when there are compelling alternatives that are full featured.

Cheers,

Ryan

On Thu, Jul 6, 2023 at 8:50 AM Watson Ladd <[e-mail]> 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. Instead I'd like to have seen
> more energy go into using forks that carry the QUIC patches we want,
> 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.
>
> Ultimately this is between application developers, operating systems
> (who decide what libraries will be system ones), the US government
> (whose FIPS process is part of the reason OS's make the decisions they
> do), 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.
>
> Sincerely,
> Watson Ladd
>
>