On Thu, Jul 6, 2023 at 6:18 PM Ryan Hamilton <rch= [email protected]> wrote:
> 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. > > I agree with Ryan that 0-RTT is a key part of QUIC's ability to perform as well as it does, and that using a library without that functionality is going to be problematic in real-world situations. I am also concerned that a patch approach like this might not work well for either connection migration or the eventual use of multipath QUIC. I appreciate Willy drawing the attention of the group to the existence of this patch and to the efforts to see if it is workable in other contexts. But I think it goes beyond ossification; this results in the amputation of deployed functionality. I cannot see any reason to recommend it. best regards, Ted Hardie > Cheers, > > Ryan > > On Thu, Jul 6, 2023 at 8:50 AM Watson Ladd <[email protected]> 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 >> >>
