I'll talk #http3 again this week and I made this new slide explaining the #OpenSSL #QUIC "journey"

Did I miss any major milestone I should add?

Technical Advisory – Hash Denial-of-Service Attack in Multiple #QUIC Implementations

github.com/ncc-pbottine/QUIC-H…

GitHub - ncc-pbottine/QUIC-Hash-Dos-Advisory

Contribute to ncc-pbottine/QUIC-Hash-Dos-Advisory development by creating an account on GitHub.

^GitHub

Let me explain the #OpenSSL #QUIC API move and what it might mean. For #curl and for others.

daniel.haxx.se/blog/2025/02/16…

OpenSSL does a QUIC API

But will it satisfy the world? I have blogged several times in the past about how OpenSSL decided to not ship the API for QUIC a long time ago, even though the entire HTTP world was hoping for it - or even expecting it.

^{daniel.haxx.se}

The state of #QUIC support in #curl is not for the faint of hearts. The current API development is what I put in the lower part of the rightmost column.

A blog post will follow to explain some of this.

An #ngtcp2 lead developer told me they have no current plans to adapt to the new #OpenSSL #QUIC API because of its lack of 0RTT support and the "pull model".

Of course someone else can go ahead and write it and ideally someone from #OpenSSL does it, for dogfooding purposes.

I have no heard of any other QUIC stack either having adapted to it yet.

I asked the #OpenSSL team about their new #QUIC API:

Out of curiosity: since you decided to provide a quite different API than what was once offered to you and what several QUIC stacks are already using. How did you come up with this API?

github.com/openssl/openssl/pul…

Add an API for other QUIC stacks to use our TLS implementation by mattcaswell · Pull Request #26683 · openssl/openssl

We provide some callbacks for third party QUIC stacks to use in order to be able to reuse the OpenSSL TLS implementation in that stack. This is essentially a thin wrapper around the same API that O...

^GitHub

It is now *six* years ago since I first blogged about how the #QUIC API situation was going to slow down QUIC (and HTTP/3) deployment. Unfortunately I was entirely correct.

daniel.haxx.se/blog/2019/01/21…

The follow-up post a few years later on OpenSSL's decision to be a laggard:

daniel.haxx.se/blog/2021/10/25…

QUIC and missing APIs

I trust you've heard by now that HTTP/3 is coming. It is the next destined HTTP version, targeted to get published as an RFC in July 2019. Not very far off. HTTP/3 will not be done over TCP.

^{daniel.haxx.se}

Three years ago I blogged about #OpenSSL's decision to deliberately block #QUIC progress in the world: daniel.haxx.se/blog/2021/10/25…

Which is timely with the OpenSSL 3.4.0 release announced just days ago: that still does not offer a working (and performant) QUIC API. (yes, there is an attempt there but it's not production grade)

It's almost like the writing was on the wall already a long time ago.

"implement the #QUIC protocol in linux kernel"

lists.openwall.net/netdev/2024…

Since #openssl does not seem to fix any of the remaining #QUIC API problems in their upcoming 3.4 release, it will keep lagging behind.

openssl-library.org/post/2024-…

I just learned there is a #QUIC in the #Linux kernel effort: github.com/lxin/quic

... as a draft PR making curl use it was filed: github.com/curl/curl/pull/1431…

Support QUIC sockets by moritzbuhl · Pull Request #14313 · curl/curl

Hi, this is still very early as the quic kernel module is still under discussion on the LKML. This is unfinished and needs a lot more modification. I would appreciate some initial feedback now befo...

^GitHub

According to @bagder the stubborn way the #OpenSSL project is handling #QUIC implementation is directly responsible for delaying HTTP/3 adoption (1), and I tend to agree. When the project rejected the community QUIC patches and decided to go with their own design, it wasn't difficult to predict problems. This was proven right by the massive feature gaps (2) and performance issues (3) discovered by @icing when trying to marry OpenSSL QUIC to #curl. Even with API fixes released in version 3.3 the implementation is still inferior, and there is no good solution in sight.

1) lwn.net/Articles/983380/
2) github.com/openssl/openssl/dis…
3) github.com/icing/blog/blob/mai…

blog/curl-h3-performance.md at main · icing/blog

Contribute to icing/blog development by creating an account on GitHub.

^GitHub

unfortunately, the new #openssl version does not do #QUIC good enough for #curl to consider removing the experimental label from it:

curl.se/mail/distros-2024-04/0…

Protocol geeks might like the new proposals on how to do #QUIC over TCP/TLS: datatracker.ietf.org/doc/html/… (called Streams) and then how to do #http3 over Streams: datatracker.ietf.org/doc/html/…

Discussed on the #HTTPbis mailing list.

Building #curl using #OpenSSL 3.2 #QUIC?

github.com/curl/curl/discussio…

Building libcurl using OpenSSL 3.2 QUIC? · curl/curl · Discussion #12425

Hello, are there any plans to build libcurl with OpenSSL v3.2's new QUIC API? OpenSSL v3.2 was officially released 11/23 (which supports QUIC client capabilities). In this way, libcurl doesn't need...

^GitHub

The #curl #http3 and #quic support egg.

(also from my coming Friday talk)

"The #OpenSSL project really seems to be in a dead end for me, it's incompatible with #QUIC and unfixable performance-wise" / Willy Tarreau

mailarchive.ietf.org/arch/msg/…

XMPP End of the Year Talk 2022!

Let's have a good time with the #XMPP Community folks!

Short talks:
- On #ActivityPub, #Movim, #Prosody development, XMPP + #QUIC

When: 6th Dec 2022, 19:00 CET (tomorrow!)
Join via this instance: bbb.sfconservancy.org/b/ste-fd…

(technical issues as always)

#jabber #standards