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 <watsonbl...@gmail.com> 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 > >
