This ticket collects information for QUIC [1][2] support and tracks, which APIs have to be added to Python in order to implement a QUIC protocol stack on top of Python's ssl and socket module. QUIC is a "UDP-Based Multiplexed and Secure Transport" protocol. It will replace TCP and TLS record layer as transport channels in the upcoming HTTP/3 [3][4] standard. Although it's UDP, QUIC does *not* use DTLS (Datagram TLS, vulgo TLS over UDP).

As far as I understand QUIC at the moment, the ssl module has to gain two additional features:

1. A way to send/receive TLS messages that are not wrapped in the TLS record layer.
2. A key callback that gets called whenever key material is exchanged during handshake or updated later on.

OpenSSL does not implement the necessary APIs, yet [5]. Tatsuhiro Tsujikawa's experimental OpenSSL fork [6] implements (1) as a SSL option SSL_MODE_QUIC_HACK and (2) as a callback that acts on five different key types.

(Disclaimer: My current understanding of QUIC is very limited.)

[1] https://tools.ietf.org/html/draft-ietf-quic-transport-20
[2] https://en.wikipedia.org/wiki/QUIC
[2] https://http3-explained.haxx.se/en/
[4] https://en.wikipedia.org/wiki/HTTP/3
[5] https://daniel.haxx.se/blog/2019/01/21/quic-and-missing-apis/
[6] https://github.com/tatsuhiro-t/openssl/commits/quic-draft-17

I have started implementing a QUIC stack in Python [1] so I'll share a couple of thoughts in addition to Christian's two valid points:

- SSLSocket is almost certainly not going to be the right entry point. QUIC's interface to TLS is entirely focused on passing in / out handshake messages and extracting secrets. No data is actually encrypted by the TLS engine.

- In addition to being notified about keying material we will need access to the raw extensions either received in the EncryptedExtensions or the ClientHello. This is because QUIC exchanges its transport parameters in the form of a TLS extension.

- We will also need additional APIs to manipulate session tickets, both when acting as a client and a server, in order to achieve 0-RTT handshakes. When acting as a client we need to be able to pass in the session ticket to use and be notified when a new session ticket is received. We also need to know the value of the max_early_data_size extension. When acting as a server we need a callback to provide the TLS engine with session tickets and to control issuing new session tickets, and provide the max_early_data_size value.

- For header protection and payload encryption we need access to a number of crypto primitives including AES, ChaCha20 and a way to use AEAD.

For aioquic I decided to use cryptography's primitives and implemented a minimal TLS 1.3 engine on top of it. This avoids having to wait for some future version of OpenSSL to provide the necessary APIs or having to use a patched version of OpenSSL.

[1] https://github.com/aiortc/aioquic

Thanks for your feedback!

So far I actively refrained from exposing or implementing any encryption primitives and API like AES, ChaCha20, and ECDSA. I'm worried about potential legal issues and export control restrictions. I have to talk to VanL first.

OpenSSL 3.0.0 is not going support QUIC, https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL/

The OpenSSL authors make a fair point, QUIC seems to be taking a long time to stabilize with little consideration for backwards compatibility at this stage.

As stated previously though it's perfectly feasible to implement a QUIC stack by linking to an unpatched OpenSSL if you're willing to implement a stripped-down TLS 1.3 engine yourself.