Chapter 2 — Networks and internet services
Lesson map
Lesson 02 published. Map, example, EX003.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Services and their secure channels"]
N2["2.2 Hybrid key exchange by protocol"]
N3["2.3 Size effects"]
N4["2.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX003"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Services and their secure channels"]
N2["2.2 Hybrid key exchange by protocol"]
N3["2.3 Size effects"]
N4["2.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX003"]
[Learning outcomes]
|
v
[2.1 Services and their secure channels]
|
v
[2.2 Hybrid key exchange by protocol]
|
v
[2.3 Size effects]
|
v
[2.5 Practical activity]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX003]
Learning outcomes
You will (1) explain DNS, HTTP, TLS, SSH and IPsec at implementation level; (2) identify key establishment and authentication in each; (3) recognise how post-quantum messages change sizes; and (4) name the standards that define hybrid key exchange in TLS, SSH and IKEv2.
2.1 Services and their secure channels
KLS's customers reach the API through DNS and HTTPS; partners exchange files over SFTP (SSH); offices connect over IPsec VPNs. Each secure channel does two jobs: key establishment (agreeing session keys) and authentication (proving identity with certificates, host keys or pre-shared keys). Quantum risk to the first is harvest-now-decrypt-later; to the second, future forgery.
The distinction decides the order of KLS's work. Recorded SFTP sessions carrying ten-year customs documents can be decrypted later if the key exchange is classical, so key establishment comes first. A forged host key or certificate only helps an attacker once a quantum computer exists and while that key is still trusted, so authentication can follow once libraries and trust stores are ready.
2.2 Hybrid key exchange by protocol
In TLS 1.3 (RFC 8446) the hybrid group X25519MLKEM768 (RFC 10024) combines ML-KEM-768 with X25519; the client key share grows from 32 to 1,216 bytes and the server share to 1,120 bytes. In SSH, OpenSSH added a hybrid ML-KEM/X25519 key exchange, mlkem768x25519-sha256, and later made it the default (OpenSSH release notes), after earlier shipping an sntrup761-based hybrid. In IKEv2, RFC 9370 allows up to seven additional key exchanges, used to add ML-KEM alongside classical Diffie–Hellman; RFC 8784 mixes post-quantum pre-shared keys as an interim measure. Terminology for such combinations is in RFC 9794.
2.3 Size effects
A ClientHello carrying an ML-KEM key share usually exceeds one 1,500-byte packet. Most stacks handle this; some middleboxes and old load balancers do not. Post-quantum signatures are larger still (ML-DSA-44: 2,420 bytes per signature in FIPS 204), which matters once certificates change. DNSSEC, which runs over UDP with tight size limits, is especially sensitive to signature size.
For KLS the size effect is measured, not assumed: the hybrid client share adds 1,184 bytes, which pushes a typical ClientHello past one segment. Lab H in Chapter 20 shows the failure signature, 1,530-byte ClientHellos timing out on one proxy path. Certificates are not touched yet, so the 2,420-byte ML-DSA-44 signature is a later concern; the DNS zone stays classical until signature sizes and resolver behaviour are understood.
2.4 Worked example
KLS enables X25519MLKEM768 on a staging API gateway. Modern browsers and the Go-based customer SDK negotiate it immediately; a customer's legacy Java client offers only classical groups and falls back to X25519, as intended. A third-party monitoring probe times out — its appliance drops the two-segment ClientHello. The fix is a probe upgrade, not disabling the group.
The staging run also gave KLS its first rollout rule. Fallback by the Java client is acceptable and is tracked as a share of sessions; a timeout is not acceptable and must be traced to a device. The monitoring vendor received a ticket with the captured ClientHello size from the lab, and the staging group list stayed unchanged while the probe was upgraded.
2.5 Practical activity
In a lab, connect to a test server with a TLS client that prints the negotiated group, once with hybrid offered and once without. Record ClientHello sizes from a capture of your own lab traffic.
Use two clients if one library cannot disable the hybrid share: for example an OpenSSL 3.5 client with default groups and the same client forced to X25519 only. Record, for each run, the negotiated group, the ClientHello length from your own capture, and whether the hello spans one or two TCP segments. Expect roughly 1,200 more bytes with hybrid. Write one sentence explaining what a middlebox that reassembles only the first segment would do to each run.
2.6 Common errors and limits
- Believing hybrid key exchange changes certificate algorithms.
- Treating SSH and TLS migrations as one task.
- Capturing traffic you are not authorized to capture.
Hybrid key exchange changes only the key-share extension; the certificate and its RSA or ECDSA signature are untouched, which is why KLS tracks certificates separately. SSH and TLS share the idea but not the software: OpenSSH's KexAlgorithms list on the SFTP hosts and the gateway's TLS group list are configured, tested and rolled back independently. Captures belong to lab traffic or authorized scopes only, because packets from customers contain their data.
Exercises
- EX003 — Protocol map. For TLS 1.3, SSH and IKEv2 name the hybrid mechanism and its defining document. Rubric: 3 = three correct with sources.
- EX004 — Byte delta. How many bytes larger is the X25519MLKEM768 server share than an X25519 share? Rubric: 3 = 1,088 bytes (1,120 − 32), noting it equals the ML-KEM-768 ciphertext.
Synthesis
Each secure channel separates key establishment from authentication. Hybrid key exchange is standardised for TLS, available in SSH and specified for IKEv2; it enlarges handshakes and can expose old middleboxes.
Continue studying — chapter 02 of 30
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →