TLS 1.3 Protocol ​
X25519MLKEM768 is implemented for both roles, as RFC 10024. We offer the hybrid group first as a client and accept it as a server, so a client that offers only the hybrid — the default for OpenSSL 3.5+ — completes the handshake. Note that
X25519MLKEM768names a key-share encoding, not a shared-secret rule: Zig's stdMlKem768X25519is X-Wing, which encodes it identically and produces a different secret.
RFC 8446 defines Transport Layer Security Version 1.3, delivering major security and performance improvements over previous TLS versions.
Key Improvements in TLS 1.3 ​
- 1-RTT Handshake: Halves handshake latency compared to TLS 1.2 by guessing the key exchange algorithm in the initial ClientHello.
- Removed Deprecated Primitives: Obsoletes static RSA key exchange, Diffie-Hellman static groups, SHA-1, MD5, and CBC ciphers in favor of Ephemeral Diffie-Hellman (ECDHE) with AEAD ciphers.
- Encrypted Handshake: Certificate messages and extensions are encrypted immediately following the ServerHello.
- Resumption (0-RTT): Pre-shared key resumption allows early data transmission on the very first round trip.
Handshake Diagram ​
Client Server
ClientHello (KeyShare, SNI, ALPN) -------->
ServerHello (KeyShare)
{EncryptedExtensions}
{Certificate}
{CertificateVerify}
<-------- {Finished}
{Finished} -------->
[Application Data] <-------> [Application Data]Key Updates ​
Both native roles implement post-handshake KeyUpdate (RFC 8446 Section 4.6.3): receive keys rotate on arrival, requested updates are answered automatically, and each sending direction enforces the RFC 9846 limit of 2^48 - 1 updates. The server exposes Connection.sendKeyUpdate() to initiate an update; clients handle updates while reading.
