Chapter 27 — Quantum and post-quantum security: verification
Lesson map
Lesson 27 published. Map, example, EX053.
flowchart TD
N0["Learning outcomes"]
N1["27.1 Verification objectives"]
N2["27.2 Checking negotiation"]
N3["27.3 Downgrade and fallback"]
N4["27.4 Evidence"]
N5["27.6 Practical activity"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX053"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["27.1 Verification objectives"]
N2["27.2 Checking negotiation"]
N3["27.3 Downgrade and fallback"]
N4["27.4 Evidence"]
N5["27.6 Practical activity"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX053"]
[Learning outcomes]
|
v
[27.1 Verification objectives]
|
v
[27.2 Checking negotiation]
|
v
[27.3 Downgrade and fallback]
|
v
[27.4 Evidence]
|
v
[27.6 Practical activity]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX053]
Learning outcomes
You will (1) define verification objectives for a migration; (2) test that hybrid key exchange is actually negotiated; (3) detect downgrade and fallback in a lab; and (4) collect verification evidence that others can reproduce.
27.1 Verification objectives
Verification asks whether the system does what the design says. For a migration, objectives include: the hybrid group is offered and selected for in-scope clients; classical fallback occurs only where permitted; certificates validate in all supported clients; performance stays within budget; and logs record the negotiated algorithms.
Each objective needs a method and an expected result written down before testing starts, so that results cannot be reinterpreted afterwards. For HCU, the objectives are applied separately to the web gateway and the branch VPN, because they use different products and fail in different ways.
27.2 Checking negotiation
Configuration says what a server offers; the handshake shows what is selected. Verify selection from the client side (test client output showing the group) and the server side (logs of negotiated groups). In TLS 1.3, the selected group appears in the cleartext ServerHello, so an authorized passive sensor can confirm it. For IKEv2, appliance logs or lab captures show the key-exchange methods negotiated under RFC 9370.
Both views should agree. If the client reports the hybrid group but server logs disagree, suspect a middlebox or a log that records offers rather than selections. HCU checks both views for each site.
27.3 Downgrade and fallback
TLS 1.3 protects negotiation integrity through the transcript-bound handshake, so an active attacker cannot simply strip the hybrid group without detection. But fallback can still happen legitimately: a client that does not support the group, or a server configured with classical groups preferred. Lab tests should include clients with and without hybrid support and confirm that each gets the expected outcome. Active downgrade experiments belong only in an isolated testbed.
Each expected outcome should be written beside the client version in the test plan.
27.4 Evidence
Record test cases, client versions, server configuration hashes, outputs and dates. A verification report lists each objective with pass, fail or not tested, plus the evidence location.
Untested objectives are listed as openly as failures, because a report that omits them overstates coverage. HCU keeps the configuration hash with each result so that a later reviewer can tell whether a pass still applies after the gateway configuration changes. A report older than the current configuration is treated as stale until the tests are rerun against it.
27.5 Worked example
HCU's lab verifies the pilot web gateway: a hybrid-capable client selects X25519MLKEM768 (pass); a legacy client selects X25519 (expected fallback, pass); the gateway's preference order was accidentally set with X25519 first, so even hybrid-capable clients chose X25519 on one test build (fail, fixed by reordering). Without the client-side check, the configuration would have looked correct.
The fix was verified by rerunning both clients after the change. The lesson for HCU was to make the client-side check a standing part of every gateway change, not only of the pilot, so that a reordered preference list is caught before it reaches members.
27.6 Practical activity
Write a verification checklist of six objectives for a hybrid-enabled HCU gateway, with method and expected evidence for each.
Include at least one objective on fallback for legacy clients and one on logging of negotiated groups. For each objective, name the client or tool used, the expected result, and where the evidence will be stored. Then mark which objectives could be checked in the lab and which need production logs, since the second kind can only be confirmed after the pilot starts.
27.7 Common errors and limits
- Verifying configuration instead of negotiation.
- Testing only modern clients.
- Running downgrade tests on production.
- Treating a single passing handshake as proof for every site and client type.
- Forgetting to recheck after a configuration change, so earlier evidence no longer matches what runs.
- Reading the server's offer list as if it were the selected group.
- Leaving untested objectives out of the report instead of marking them as not tested.
Each of these makes a report look more complete than the evidence behind it.
Exercises
- EX053 — Offer versus select. Explain how a server can offer a hybrid group yet never select it. Rubric: 3 = preference order or client support explained.
- EX054 — Evidence record. List five fields every verification record should contain. Rubric: 3 = five relevant fields.
Synthesis
Verification checks negotiated behaviour, fallback paths and evidence, not just configuration; reproducible records turn tests into assurance.
Continue studying — chapter 27 of 40
← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →