Chapter 7 — Networks and protocols
Lesson map
Lesson 07 published. Map, example, EX013.
flowchart TD
N0["Learning outcomes"]
N1["7.1 Layers and secure channels"]
N2["7.2 The TLS 1.3 handshake"]
N3["7.3 Size and middleboxes"]
N4["7.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX013"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 Layers and secure channels"]
N2["7.2 The TLS 1.3 handshake"]
N3["7.3 Size and middleboxes"]
N4["7.5 Practical activity"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX013"]
[Learning outcomes]
|
v
[7.1 Layers and secure channels]
|
v
[7.2 The TLS 1.3 handshake]
|
v
[7.3 Size and middleboxes]
|
v
[7.5 Practical activity]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX013]
Learning outcomes
You will (1) describe the TCP/IP layers and where TLS, IPsec and SSH operate; (2) trace a TLS 1.3 handshake and identify key exchange and authentication; (3) explain why post-quantum keys and signatures stress message sizes; and (4) name the IETF documents that define hybrid key exchange.
7.1 Layers and secure channels
Data crosses networks in layers: link, internet (IP), transport (TCP, UDP, QUIC) and application. Secure channels insert cryptography at different points. TLS protects application streams such as HTTPS; IPsec with IKEv2 protects IP packets between sites, as in HCU's branch VPNs; SSH protects administrator sessions. Each has two cryptographic jobs: key establishment, which agrees a fresh session secret, and authentication, which proves who the peer is, usually with certificates and signatures.
The two jobs face different quantum threats. Key establishment matters for harvest now, decrypt later, because recorded traffic can be opened once the session secret is recovered. Authentication matters only at the moment of connection, since a forged signature later cannot change a past handshake.
7.2 The TLS 1.3 handshake
In TLS 1.3 (RFC 8446) the client sends a ClientHello listing supported groups and a key share; the server answers with a ServerHello holding its key share, then encrypted messages carrying its certificate chain and a CertificateVerify signature. Key establishment and authentication are separate: a hybrid group such as X25519MLKEM768, specified for TLS in RFC 10024, replaces only the key-exchange part. Its client key share is 1,216 bytes and its server share 1,120 bytes, against 32 bytes for X25519 alone. The certificate chain is unchanged until post-quantum certificates are deployed.
7.3 Size and middleboxes
Bigger messages matter. A ClientHello above about 1,500 bytes may span two TCP segments; some old firewalls and inspection devices mishandle such messages or unknown group identifiers. Post-quantum signatures are larger still: an ML-DSA-44 signature is 2,420 bytes (FIPS 204), versus about 72 for ECDSA P-256. Chapter 30 measures what this does to certificate chains.
Before blaming the new algorithm for a failure, check where the bytes went. A packet capture in a lab shows whether a message was split, dropped or rejected, and by which device.
7.4 Worked example
HCU's network team sees a rise in failed connections after enabling a hybrid group on a test web gateway. A packet capture in the lab shows the ClientHello now spans two segments, and a legacy inspection proxy at one branch drops the connection. The fix is not to disable post-quantum key exchange everywhere but to update or bypass that proxy, while recording the issue in the migration log. The diagnosis needed knowledge of both layers: the size came from cryptography, the failure from transport handling.
7.5 Practical activity
Using a lab browser and your own test server, or published handshake traces, identify the supported-groups list in a ClientHello and the selected group in the ServerHello. Record which messages are encrypted in TLS 1.3. Do not capture other people's traffic.
Most of the handshake after the ServerHello is encrypted in TLS 1.3, including the certificate, so a passive observer sees less than in older versions. Compare a connection that offers a hybrid group with one that offers only classical groups, and note the difference in ClientHello size. Published traces are a safe alternative if you have no test server of your own. Write down which tool you used and its version, so another student can repeat the observation.
7.6 Common errors and limits
- Believing hybrid key exchange also makes authentication post-quantum.
- Blaming the algorithm for failures caused by middleboxes.
- Capturing traffic on networks you are not authorized to monitor.
Hybrid key exchange protects session secrets against later decryption, but the certificate and its signature remain classical until certificates change, which is a separate and slower migration. Middlebox failures are common in early deployments, and diagnosing them needs evidence from the network, not assumptions about the algorithm. Capturing traffic without authority is unlawful in many places and breaks the trust that security work depends on, however good the intention.
Exercises
- EX013 — Split the jobs. For TLS 1.3, IKEv2 and SSH, name the key-establishment and the authentication mechanism in a typical classical deployment. Rubric: 3 = six correct entries.
- EX014 — Size budget. How many more bytes does a client send in its key share with X25519MLKEM768 than with X25519 alone? Rubric: 3 = 1,184 bytes with sizes cited.
Synthesis
Secure protocols separate key establishment from authentication. Hybrid post-quantum key exchange changes the first, enlarges handshakes and can expose old middleboxes; authentication changes later with post-quantum certificates.
Continue studying — chapter 07 of 40
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →