Open krizhanovsky opened 6 years ago
An implementation should (not must, https://tools.ietf.org/html/rfc8446#section-9.1) implement ChaCha20 and the algorithm is slow (the only reason for it is that its pure software implementation is faster than AESs):
$ openssl speed -elapsed -evp chacha20
....
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
chacha20 274069.48k 519363.26k 1022813.35k 2116939.78k 2215616.51k 2121307.48k
$ openssl speed -elapsed -evp aes-128-gcm
...
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-gcm 377061.18k 936625.90k 1908564.48k 3045661.35k 3836799.66k 3876809.39k
$ openssl speed -elapsed -evp aes-256-gcm
...
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-256-gcm 326535.54k 833587.56k 1561193.39k 2327310.68k 2718223.02k 2836157.78k
TLS 1.3 is defined in RFC 8446 and partially implemented in our donor, mbedTLS. Current Tempesta TLS moves far from mbedTLS, so a new features from mbedTLS can not be ported as is.
The task requires some of the items from #1335 for the cypro math, but in this task we can start just with borrowing some code from mbed TLS and leave performance optimizations for #1335.
At least following functionality must be implemented in the first pull request. Probably it makes sense to make a separate pull request for each of the points.
mbedtls_ssl_psk_derive_premaster()
must be completely different as well as format of the PSK extension in key exchange record. Anyway, we still don't need out-of-band distributed keys - the main part of the removed code. It seems none of a real clients, like browswers, actually support 0rtt due to it's security issues - please check this for Chrome and Firefox and move this to a separate issue.The implementation must consider QUIC #724 requirements (RFC 9001) and develop necessary TLS 1.3 routines for it. Basically QUIC isn't a layered protocol, so it requires specific TLS 1.3 interfaces. See picotls and its usage in quant for an example of QUIC/TLS1.3 interoperability.
According to RFC 8740 we must not support post-handshake CertificateRequest messages, but must implement key updates and NewSessionTicket messages.
Move Tempesta TLS to 0.4.0 version on implementing the extension.
Related project for the Linux kernel TLS 1.3 handshakes https://github.com/lxin/tls_hs/
Testing
As part of the issue (during the debugging) please develop functional tests
tls/
for TLS 1.3 like #737 . Note that the current scapy-ssl_tls implementation of TLS 1.3 is outdated, so the native Sapy TLS layer must be used.