Thread by @programmingart

I wrote a blog post looking at potential threats for #QUIC and HTTP/3 adoption and deployment calendar.perfplanet.com/2018/quic-and-…. This will also be the basis for a talk at the HTTP symposium at curl-up in Prague at the end of March 2019 github.com/curl/curl-up/w…

Yesterday, there was a #QUIC workshop at the #conext18 conference with a large amount of new insights. Most of my notes on this can be found at docs.google.com/document/d/16S…. Following tweets contain the parts relevant to the blogpost.

For example, Intel was here with a demo of a NIC that can offload #QUIC crypto to hardware. When asked later, Manasi Deval mentioned that specifically Variable Integer Encoding (to reduce the amount of bits on the wire) is a serious hindrance for #QUIC hardware support.

@__subodh from Facebook was worried about the fact that the cryptographic handshake in #QUIC has not yet been formally verified (though TLS1.3 has been vetted) and still might contain major flaws. If one is found, it might lead to all #QUIC deployments being pulled until fixed.

Luckily, #QUIC is built to be evolvable, so depending on the complexity of the fix to protect against the new attack, the downtime might be minimal or major.

@grittygrease from Cloudflare mentions a possible future where the end-to-end encryption properties of #QUIC will be actively opposed by networks and especially governments.

@__subodh also made a prediction that #QUIC might not make sense for everything. It might be primarily interesting for client-to-edge connections, where the backbone continues to use TCP. Manasi Deval did see #QUIC becoming the new default standard in the future.

Though nothing definite, early conversations between Facebook and network operators shows they are neutral/slightly positive, but not outright negative towards #QUIC, as the protocol improves end-user experience and this is the #1 metric for operators.

Finally, Facebook is indeed doing some shenanigans with the Connection ID to ensure their infrastructure works for #QUIC (e.g., adding no-downtime server upgrades with ProcessID and debugging failing packet routing by adding a server ID). It's doable and flexible, but non-trivial