Jeremy Lainé <jeremy.la...@m4x.org> added the comment: 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 ---------- nosy: +jlaine _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37048> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
