Day 17: IETF Hybrid TLS — Extensions and Named Groups

Phase 3 · July 24, 2026

Agenda (2–3 hours)

• Read (60 min): IETF draft-ietf-tls-hybrid-design §4–6 (TLS integration); draft-ietf-tls-ecdhe-mlkem (X25519Kyber768 named group spec)
• Study (45 min): How hybrid key shares fit into TLS 1.3 extensions; current deployment status
• Challenge (45 min): Annotate a hybrid TLS ClientHello

How Hybrid Groups Fit Into TLS 1.3

TLS 1.3 already has the infrastructure: key_share and supported_groups extensions.
PQC hybrid simply adds new named group codes:

Existing groups:
  x25519        = 0x001D
  secp256r1     = 0x0017

Hybrid PQC groups (IETF drafts):
  X25519Kyber768Draft00  = 0x6399  (Cloudflare/Google experimental)
  X25519MLKEM768         = 0x11EC  (latest IETF draft)

A client that supports hybrid TLS includes X25519MLKEM768 in its supported_groups
and sends the combined key share (32 + 1184 = 1216 bytes) in key_share.

Hybrid ClientHello key_share

Extension: key_share
  NamedGroup: X25519MLKEM768 (0x11EC)
  key_exchange (1216 bytes):
    [0:32]     X25519 ephemeral public key (32 bytes)
    [32:1216]  ML-KEM-768 encapsulation key (1184 bytes)

Server responds in ServerHello:

Extension: key_share
  NamedGroup: X25519MLKEM768 (0x11EC)
  key_exchange (1120 bytes):
    [0:32]     X25519 server ephemeral public key (32 bytes)
    [32:1120]  ML-KEM-768 ciphertext (1088 bytes)

Total key_share data exchanged: 1216 + 1120 = 2336 bytes (vs 64 bytes for X25519).
This adds ~1 TCP segment to the handshake on many networks — usually acceptable.

Current Deployment Status (as of 2026)

The IETF draft is close to RFC status. Production deployment is happening now.
Your service can enable it today using rustls with the aws-lc-rs provider.

Downgrade Safety

What if a server doesn't support hybrid groups?

Client offers: [X25519MLKEM768, x25519, secp256r1]
Server (no PQC): picks x25519 → falls back to classical

Client offers: [X25519MLKEM768]  (PQC only, no fallback)
Server (no PQC): sends HelloRetryRequest or handshake_failure

For a provisioning service (server-controlled): you can mandate hybrid on day 1.
For a client-facing service (browsers etc.): offer hybrid + classical fallback.

Your provisioning service talks to your own Lambda clients — mandate hybrid.

Enabling in rustls-aws-lc-rs

use rustls::{ClientConfig, RootCertStore};
use rustls_aws_lc_rs::AwsLcRsProvider;

// Install aws-lc-rs as the default crypto provider
rustls_aws_lc_rs::default_provider().install_default()?;
// This enables X25519MLKEM768 as a supported key exchange group automatically

let config = ClientConfig::builder()
    .with_root_certificates(roots)
    .with_no_client_auth();
// X25519MLKEM768 will be offered in supported_groups + key_share

Challenge Assignment

Using a Wireshark capture of a hybrid TLS connection (or Chrome connecting to cloudflare.com):

1. Find the supported_groups extension in ClientHello — is X25519Kyber768 or X25519MLKEM768 present?
2. Find the key_share extension — what is the total size of the client's hybrid key share?
3. Find the server's key_share in ServerHello — which group was selected?

If you can't capture a live hybrid session, use the IETF draft appendix's example values.

Then: write 1 paragraph for your migration roadmap on when to enable hybrid TLS in your service — specifically, what client-side changes are needed and whether there are backward-compatibility concerns.

Resources

• IETF draft-ietf-tls-ecdhe-mlkem: latest version on datatracker.ietf.org
• IETF draft-ietf-tls-hybrid-design: the design rationale
• Cloudflare blog: "The state of the post-quantum Internet"
• rustls-aws-lc-rs: docs.rs — CryptoProvider and supported groups