Hi all, as the subject says it, Fred managed to make QUIC mostly work on top of a regular OpenSSL. Credit goes to the NGINX team who found a clever and absolutely ugly way to abuse OpenSSL callbacks to intercept and inject data from/to the TLS hello messages. It does have limitations, such as 0-RTT not being supported, and maybe other ones we're not aware of. I'm hesitating in merging it because there are some non-negligible impacts for the QUIC ecosystem itself in doing this, ranging from a possibly lower performance or reliability that could disappoint some users of the protocol, to discouraging the efforts to get a real alternative stack working.
I've opened the discussion on the QUIC working group here to collect various opinions and advices: https://mailarchive.ietf.org/arch/browse/quic/?gbt=1&index=M9pkSGzTSHunNC1yeySaB3irCVo Unsurprizingly, the perception for now is mostly aligned with my first feelings, i.e. "OpenSSL will be happy and QUIC will be degraded, that's a bad idea". But I also know that on the WG we exclusively speak between implementors, who don't always have the users' perspective. I would encourage those who really want to ease QUIC adoption to read the thread above (possibly even share their opinion, that would be welcome) so that we can come to a consensus regarding this (e.g. merge, drop, merge conditioned at build time, or with an expert runtime option, anything else, I don't know). I feel like it's a difficult stretch to find the best approach. The "it's not possible at all with openssl, period" excuse is no longer true, however "it's only a degraded approach" remains true. I wouldn't like end-users to just think "pwah, all that for this, I'm not impressed" without realizing that they wouldn't be benefitting from everything. But maybe it would be good enough for most of those who are not going to rebuild QuicTLS or wolfSSL. I sincerely don't know and I do welcome opinions. Cheers, Willy
