Jeremy Lainé 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
<https://bugs.python.org/issue37048>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
