Chapter 1 — Research question and literature method
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes and connection"]
N1["1.1 From complaint to question"]
N2["1.2 Why size is plausible"]
N3["1.3 FINER"]
N4["1.4 A documented search"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["1.1 From complaint to question"]
N2["1.2 Why size is plausible"]
N3["1.3 FINER"]
N4["1.4 A documented search"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX001"]
[Learning outcomes and connection]
|
v
[1.1 From complaint to question]
|
v
[1.2 Why size is plausible]
|
v
[1.3 FINER]
|
v
[1.4 A documented search]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes and connection
You will (1) turn an operational complaint into a researchable question; (2) apply the FINER test (feasible, interesting, novel, ethical, relevant); (3) design a documented literature search across standards, academic and practitioner sources; and (4) build an evidence table. The chapter builds on your entry knowledge and prepares the seminar of Chapter 2.
1.1 From complaint to question
"Post-quantum broke the internet for the hospital wing" is a complaint. It mixes an intervention (offering X25519MLKEM768), an outcome (users cannot load sites), a population (hospital-wing users) and an implied cause (post-quantum cryptography). A research question separates them and makes the cause something to test rather than assume. Draft one: Did failures increase? — answerable but descriptive. Draft two: Did failures increase more on the proxy path than the direct path? — comparative. Draft three, the Fragment Study question above: how much of the increase is attributable to multi-packet ClientHello handling, and where? — explanatory and bounded. The third draft is harder but is what a dissertation should attempt, because it can inform a decision (fix the proxy, or roll back the group) and can be wrong.
1.2 Why size is plausible
A traditional X25519 key share is 32 bytes. ML-KEM-768's encapsulation key is 1,184 bytes (FIPS 203, Table 3), so the X25519MLKEM768 client share is 1,216 bytes and the server's reply share — ML-KEM ciphertext of 1,088 bytes plus 32 — is 1,120 bytes (RFC 10024). A ClientHello that previously fitted in one TCP segment now often needs two. TLS 1.3 itself handles this (RFC 8446 records can span segments), but software that reads only the first packet to make a routing or inspection decision may fail. The mechanism is specific, which makes it testable.
1.3 FINER
Feasible: Larkspur's proxy and browser telemetry already log handshake outcomes (synthetic). Interesting: every organization enabling hybrid groups faces the question. Novel: public reports are mostly vendor or browser-wide; few studies attribute failures within one organization with competing explanations tested. Ethical: logs can be minimized to metadata (Chapter 3). Relevant: the answer decides between rolling back quantum protection and repairing infrastructure.
Write the FINER check into the proposal with one sentence of evidence for each letter, not just a tick. For feasibility, name the log sources and confirm with the network team that they keep handshake outcomes for long enough. For novelty, point to the evidence table, where the gap in within-organization attribution is visible.
1.4 A documented search
Search three source families separately. Standards: RFC Editor and IETF datatracker for TLS hybrid key exchange, ML-KEM in TLS, and ClientHello size. Academic: IACR ePrint, ACM/IEEE/USENIX digital libraries, terms "post-quantum TLS performance", "hybrid key exchange deployment", "middlebox ossification". Practitioner: browser and CDN engineering blogs, which hold most deployment evidence but are written by interested parties. Record date, database, string and hit counts for each search so that a reader can rerun it — this is the master's-level equivalent of a lab notebook.
1.5 Worked example: the evidence table
| Source | Type | Claim relevant to question | Evidence | Limit |
|---|---|---|---|---|
| RFC 10024 | Standard | Defines sizes of hybrid shares | Specification | Says nothing about failure rates |
| Chromium Blog 2023 | Practitioner | Larger ClientHello exposed middlebox bugs | Deployment observation | Browser-wide; no per-network attribution |
| tldr.fail | Community | Some servers mishandle split ClientHello | Curated list | Not a sample; selection unknown |
| FIPS 203 | Standard | ML-KEM sizes | Specification | — |
The table reveals the gap: mechanisms and anecdotes exist, attribution within an organization does not.
Add a row for each new source as the search proceeds, and keep the limit column honest even for sources that support the question. The P-7 paper discussed in the seminar would enter the table with its 240% claim and a limit noting the missing base rate. A reader should be able to see from the table alone why the study is needed.
1.6 Common errors and limits
- Letting the complaint's implied cause become the hypothesis without rivals.
- Searching only academic databases in a field where deployment evidence lives in engineering blogs.
- Treating a curated list (tldr.fail) as a random sample.
- Unrecorded searches that cannot be rerun.
Each error has a guard. Write rivals before choosing a hypothesis, as Chapter 4 does with five of them. Search engineering blogs as a separate family with its own limits. Describe tldr.fail as curated, not sampled. Keep a search log with date, database, string and hit count for every run, so an examiner can repeat it.
Exercises — chapter 1
- EX001 — Decompose a complaint. Split "PQC broke Wi-Fi in the library" into intervention, outcome, population and implied cause. Rubric: 3 = all four plus one rival cause.
- EX002 — Three drafts. Write descriptive, comparative and explanatory versions of a question about hybrid groups and VPNs. Rubric: 3 = explanatory version bounded and testable.
- EX003 — Size arithmetic. Compute client and server key-share sizes for SecP384r1MLKEM1024 using FIPS 203 ML-KEM-1024 sizes (1,568-byte encapsulation key and ciphertext) and a 97-byte uncompressed P-384 point. Rubric: 3 = both sizes correct with sources.
- EX004 — FINER. Apply FINER to your own question. Rubric: 3 = each criterion argued, at least one weakness admitted.
- EX005 — Search log. Write a search log with three databases, strings and dates. Rubric: 3 = rerunnable.
- EX006 — Evidence table. Add two rows from sources you verify yourself. Rubric: 3 = sources primary or clearly labelled practitioner, limits stated.
- EX007 — Gap statement. Write the gap in one sentence. Rubric: 3 = names missing evidence precisely.
Chapter synthesis
A researchable question separates intervention, outcome, population and cause, rests on a specific mechanism and is supported by a rerunnable search across standards, academic and practitioner sources.