{"id":"fb001316-a459-43f5-8556-f1ae6ad8db7d","arxiv_id":"2412.08936","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"QFAM modifies the QUIC Retry token to include a cryptographic challenge (proof-of-work) that clients must solve before the server allocates handshake CPU.","lead":"QFAM embeds a proof-of-work puzzle into QUIC's Retry token, so a server under handshake flood asks clients to burn CPU before the server spends resources. The paper reports that this shifts CPU load from the server to the attacker on a small testbed, but key details like attack detection and puzzle difficulty are left open.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"QFAM does not gate the server's Retry-token work: an attacker who ignores challenges can still force per-CHLO AES-GCM token generation, and the paper never measures this unsolved-flood regime.","rationale":"The reader's conditional focused on the unspecified detector and the false-positive/false-negative contradiction. I see a different, more direct condition: the defense's own two-branch analysis. In the branch where the attacker solves challenges, the mechanism works as the experiments show. In the branch where the attacker ignores challenges, QFAM still requires server work per packet, and the paper asserts rather than demonstrates that this branch is harmless. Since a flooding attacker controls its own behavior, a rational adversary chooses the branch with the lowest cost, which is the unsolved-flood branch. The experimental section effectively evaluates a cooperative attacker, not an adversarial one. This is the load-bearing soft spot. It does not make the idea nonsensical; it means the central claim rests on an unmeasured quantity: the cost of Retry-token generation relative to packet-sending cost under an unsolved flood. A straightforward experiment can settle it. Until then, the verdict remains conditional, consistent with the reader's overall assessment, but with the condition re-focused on the unsolved-flood attack branch rather than on detector reliability. No questions of author integrity are involved; the critique is purely about the argument and evidence.","tokens_in":16495,"tokens_out":11109,"duration_ms":122217,"concrete_test":"Re-run the Section 5 testbed with QFAM in mitigation mode at the highest CCI (15), but modify the attacker to discard all Retry packets and continue sending fresh unsolved Initial/CHLO packets, exactly the branch discussed in Section 5.2.3. Measure server CPU utilization and CPU amplification factor as a function of offered CHLO rate up to saturation, and compare to the no-mitigation curve in Figure 7. If the server can be driven to 100% CPU at an offered rate that a modest distributed attacker can achieve, with server CPU per request still exceeding attacker CPU per request, then the claim that DDoS is naturalized fails; if the server saturates only at, say, more than 10x the rate of the no-mitigation baseline, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"QFAM's gate is placed before the expensive TLS key-exchange, but after a server-side token-generation step. In mitigation mode, every Initial/CHLO that lacks a valid solved token (or that the attacker abandons after receiving the Retry) still triggers the server to construct an enhanced RETRY packet: one AES-128-GCM encryption of the Token Body plus ICV computation over the associated data in Eq. (1) and Section 4.1.3. Section 4.5 correctly notes this server work is O(1), but O(1) is not zero; it is work an attacker can request for free by not solving the puzzle. The paper's statement in Section 5.2.3 that if the attacker 'chooses not to solve the challenges... the server would not dedicate resources to process its CHLOs' is inaccurate: the server dedicates Retry-generation resources before challenge verification can take place. The evaluation never measures this branch. Figure 10 only tests an attacker that attempts to solve challenges (the defense's best case); Section 5.2.3's 'attacker chooses not to solve' branch is asserted without data. Thus the central claim that choosing difficulty reduces, let alone 'naturalizes,' CPU amplification is unsupported for the cheapest rational attack behavior: flooding unsolved CHLOs and discarding Retry packets. Whether the residual per-CHLO server cost is small enough to prevent CPU exhaustion under a realistic flood is exactly the missing measurement.","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes QFAM, a defense against QUIC handshake flooding attacks based on cryptographic challenges embedded in the QUIC Retry token. When the server detects an attack, it sends an enhanced Retry packet whose token contains a 4-bit Challenge Complexity Index and a 64-bit Token Identifier Number; the client must find a 28-bit Matched Random Number such that a hash of the token fields has the required number of leading zeros. The server verifies the solution in O(1) and only then proceeds with the expensive TLS key exchange. The authors integrate this into aioquic and evaluate on a LAN with one server, one attacker, and one legitimate client, measuring CPU usage, attack rate, challenge solving time, and legitimate-client response time across difficulty levels and attack rates. The paper claims that this reduces the CPU amplification factor and naturalizes the DDoS vulnerability.","tokens_in":16751,"tokens_out":8703,"duration_ms":88149,"significance":"If the mechanism worked as claimed, QFAM would be a useful, protocol-compatible addition to QUIC defenses: it shifts a tunable amount of handshake CPU cost to clients during attacks and can complement detection-based systems. The complexity argument is straightforward (O(2^n) client work versus O(1) server verification), the token-format modifications are concrete, and the authors correctly note that the approach does not require per-flow classification. However, the evaluation is far too thin to establish the central claim: it contains no repeated trials, error bars, comparison defenses, or measurements of the unsolved-flood branch, and the activation condition (attack detection) is left unspecified. The residual per-CHLO Retry-generation work may be small, but it is not measured. The paper's potential impact is therefore moderate but currently not demonstrated.","major_comments":[{"comment":"The paper states that if the attacker chooses not to solve the challenge, \"the server would not dedicate resources to process its CHLOs.\" This is inaccurate: before challenge verification can occur, the server must generate an enhanced RETRY packet for every Initial/CHLO that lacks a valid solved token. That generation includes the AES-128-GCM encryption of the Token Body and the ICV computation over the associated data A in Eq. (1) (Section 4.1.3). This per-CHLO work is O(1), but O(1) is not zero, and an attacker can request it cheaply by flooding unsolved CHLOs and discarding the RETRY packets. Figure 10 only measures an attacker that attempts to solve the challenges, and Section 5.2.3's unsolved-flood branch is asserted without data. The central claim that CPU amplification is naturalized requires either a measurement of the server's residual per-unsolved-CHLO cost under a maximal unsolved flood, or a revised claim limited to attackers who solve challenges.","section":"Section 5.2.3 and Eq. (1)"},{"comment":"The claim that \"our approach does not suffer from the consequence of false positives or false negatives\" (Section 4) is contradicted by the activation mechanism in Section 4.6: the cryptographic challenges \"are only used when the server detects handshake flooding attacks.\" No detector is specified. A false negative leaves the server in normal mode and fully exposed to the CPU-amplification attack; a false positive forces all legitimate clients to solve puzzles during a non-attack. Since QFAM's protection is gated by this unspecified detector, the no-FP/FN statement overstates what is demonstrated. The paper should either specify a detection scheme with an error analysis or weaken the claim to say that QFAM does not itself classify individual flows.","section":"Section 4 and Section 4.6"},{"comment":"The evaluation is a single LAN testbed with one server, one attacker, and one legitimate client. There are no repeated trials, error bars, confidence intervals, or statistical hypothesis tests, and no comparison against QUICShield, QUICwand, QUICPro, or a standard Retry-only baseline. The figures show plausible trends, but they cannot support quantitative statements such as \"the CPU amplification factor ... reached over 6\" or the response-time curves in Figure 12. At minimum, the paper should report variance and run the attack-rate and complexity sweeps multiple times.","section":"Section 5.1 and Figures 7-12"},{"comment":"The 4-bit CCI limits the challenge to at most 15 leading zeros, i.e., an expected 2^15 hash evaluations. This is a very modest proof-of-work on modern hardware; Section 5.2.3's Figure 9 shows that even with complexity 15, the single-core attacker can still sustain roughly 20 solved requests per second, and the paper provides no analysis of what happens with multi-core attackers or botnets. Because the claimed defense relies on properly choosing the difficulty level to balance CPU consumption, the manuscript needs to either justify that 2^15 is sufficient for the threat model or extend the CCI field.","section":"Section 4.1.3 and Algorithm 1"}],"minor_comments":[{"comment":"The abstract contains a grammatical error: \"during of handshake flooding attacks.\"","section":"Abstract"},{"comment":"The text refers to a Challenge Complexity Index of \"1100\" and then explains it is decimal 12; write it as binary 1100 (12) to avoid confusion.","section":"Section 5.2.4"},{"comment":"Figure 12 includes attack rates up to 120 Req/s, while Section 5.2.1 states that the server was fully saturated at 100 Req/s; clarify whether the curves in Figure 12 assume mitigation mode is active at all complexity levels.","section":"Section 5.2.6 and Figure 12"},{"comment":"The discussion says clients that do not support mitigation can still connect by treating the enhanced Retry token as a standard token; the paper should explain how the server distinguishes a client that ignored the challenge from one that solved it, given that both return the same token fields.","section":"Section 6"},{"comment":"Minor typographical issues include \"a secrete\" in Section 4.1, \"regrading\" and \"bothe\" in Figure 3, and \"poses a cryptographic challenge\" in Section 4.","section":"Section 4.1 and Figure 3"},{"comment":"The packet labels in Figure 1 use \"Intial\" instead of \"Initial\".","section":"Figure 1"}],"recommendation":"major_revision","confidential_remarks":"The core idea is reasonable and the protocol-level integration is concrete, but the evidentiary basis is too weak for the paper's strong claims, and the unsolved-flood attack is a genuine gap. The issues are addressable with additional measurements, a specified or scoped detection story, and more careful wording, so this should not be rejected outright."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: the paper has a sensible idea—embed a proof-of-work in QUIC's Retry token—but it never tests the attack mode that matters most: the attacker who ignores the puzzle and just floods unsolved ClientHellos. As written, the central claim that server CPU amplification is reduced isn't supported.\n\nWhat's good: the token-format design is concrete and respects the existing QUIC structure. They split the 96-bit unique number into TIN/MRN/CCI, define the AEAD associated data, and give a clear algorithm for the client puzzle. They also implement it in aioquic and show that when the attacker does solve puzzles, its CPU rises and the induced attack rate falls. That direction-of-effect evidence is fine for a workshop paper.\n\nThe soft spots, in order of weight. First, the unsolved-flood branch. Section 5.2.3 says that if the attacker doesn't solve the challenge, \"the server would not dedicate resources to process its CHLOs.\" That's not accurate: before the server can verify any solution it first generates a Retry packet, which includes an AES-GCM encryption and an ICV. The paper's own Figure 10 only runs attackers that try to solve the puzzle, so the cheapest rational attack—send CHLOs, discard the Retries—is never measured. Whether the residual per-CHLO cost is still small enough to stop CPU exhaustion is exactly the missing experiment. Second, the evaluation is one run, no error bars, one attacker and one client on a LAN. That's fine for a demonstration but not for the strong claim that the vulnerability is \"naturalized.\" Third, the maximum difficulty is 15 bits of leading zeros. A modern CPU can do that in milliseconds; a real flood would just solve them. Fourth, they repeatedly say the approach avoids false positives and negatives, then Section 4.6 says the challenge is only activated when the server detects an attack. The detector is unspecified, so false negatives leave the server exactly where it was.\n\nThis isn't a fatal flaw—the idea may be usable—it's an unproven one. The paper is for QUIC/transport-security people who want to see what a client-puzzle Retry token could look like. It deserves a serious referee: the design is coherent enough to critique, and the missing experiment is fixable. I'd send it out, but the main claim needs to be pulled back until they measure the unsolved-CHLO flood.","headline":"Plausible puzzle-in-Retry idea, but the evaluation skips the cheapest attack, leaving the central claim unproven.","tokens_in":17337,"tokens_out":2592,"would_cite":false,"duration_ms":26148,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"By embedding a proof-of-work puzzle in QUIC's RETRY token, a server can push the CPU cost of a handshake flood onto the attacker and shrink the amplification factor.","keywords":["QUIC","handshake flooding","proof-of-work","RETRY token","CPU amplification","DDoS mitigation","cryptographic challenge","address validation"],"falsifier":"Run the paper's one-server, two-client testbed with an intentionally flawed detector, e.g., a fixed threshold that misses a slow ramp-up of handshake requests, and show that a moderate flood below the threshold still drives server CPU to saturation because no challenges are issued; or, on the calculation side, show that at maximum difficulty the expected client solve time is so low that a botnet with many cores can still sustain an attack rate that exhausts the server.","tokens_in":16266,"feed_emoji":"🧩","tokens_out":5539,"duration_ms":51880,"temperature":0.7,"pith_summary":"QFAM proposes to modify the QUIC RETRY token so that, when the server suspects a handshake flooding attack, each client must solve a cryptographic puzzle before its connection request gets full server-side processing. The puzzle is a hash preimage search: the client must find a random value such that a hash output has a required number of leading zeros, with the difficulty set by the server. Because solving the puzzle costs the client exponential work while the server verifies in constant time, the CPU amplification that makes QUIC handshake floods dangerous is reduced. The paper argues this is a root-cause fix rather than a detection-and-filtering approach, and reports testbed experiments on an open-source QUIC implementation showing attacker CPU rises and the achievable attack rate falls as challenge difficulty increases. If correct, the scheme gives QUIC servers a tunable knob to rebalance resource consumption during floods without blocking traffic.","feed_headline":"A puzzle in QUIC's RETRY token flips DDoS cost onto attackers","feed_subtitle":"Proof-of-work challenges let a QUIC server shrink the CPU amplification that handshake floods exploit.","key_machinery":"The load-bearing object is the enhanced RETRY token, a drop-in modification of the RFC 9000 Retry token: its 96-bit Unique Token Number is split into a 64-bit Token Identifier Number, a 28-bit Matched Random Number, and a 4-bit Challenge Complexity Index. The client solves the challenge by finding a 28-bit value $R$ such that $Z = h(\\mathrm{ICV} \\| \\mathrm{TIN} \\| \\mathrm{Port} \\| \\mathrm{CCI} \\| R)$ has at least $\\mathrm{CCI}$ leading zeros; the server checks the same hash in constant time. The token remains a valid QUIC address-validation token for clients that do not support the enhancement, so those requests can be deprioritized rather than dropped.","core_discovery":"The central claim is that the QUIC handshake's CPU amplification vulnerability can be neutralized at its source by folding a cryptographic challenge into the existing address-validation RETRY token. The server's enhanced token carries a 4-bit Challenge Complexity Index and a 64-bit token identifier; the client must append a 28-bit matched random number so that the hash of the token fields plus its answer has the specified number of leading zeros. The server's verification requires only one hash and token check, so the client's expected work grows as $O(2^n)$ while the server's stays $O(1)$. With a suitable difficulty level the attacker spends more CPU per accepted handshake than the server, eliminating the amplification factor rather than merely detecting the flood.","pith_inferences":["The same challenge-in-token pattern could be applied to other stateless transport handshakes, such as TCP SYN cookies or DTLS, that suffer from CPU amplification, though each protocol's token format would need a similar extension.","The scheme effectively converts a network-layer flood into an economic problem: puzzle difficulty is a price on connection establishment, and if the server can estimate its own CPU cost per handshake it can set difficulty to make each forged request net-negative for the attacker.","A testable extension is to benchmark the scheme under distributed botnet attacks where parallel puzzle solvers can be aggregated, since the single-client LAN experiment may not capture whether a difficulty setting that balances CPU there still protects a server against many attackers solving puzzles in parallel.","The paper's claim that the approach does not suffer from false positives or false negatives is only exactly true if the attack detector is perfect; a more precise statement is that misdetection changes the cost allocation rather than causing outright blocking."],"forward_implications":["When mitigation mode is on, an attacker that solves puzzles sees its achievable attack rate drop as difficulty rises, because each accepted request costs it real CPU.","An attacker that refuses to solve puzzles no longer triggers expensive server-side key shares, so the CPU amplification collapses.","Legitimate clients face a bounded delay from puzzle solving; at high attack rates this delay is smaller than the latency caused by the server being overloaded.","The server can tune difficulty dynamically through the 4-bit Challenge Complexity Index, trading attacker cost against legitimate-client overhead.","The approach is a proactive complement to existing reactive defenses and does not block clients that lack the enhanced token; unmodified clients can still connect at lower priority."],"supporting_citations":[{"why":"Establishes the vulnerability QFAM targets by measuring a CPU amplification factor of up to 4.6 for QUIC handshake flooding relative to TCP.","marker":"[37]"},{"why":"Shows that address validation is often disabled in real QUIC deployments, motivating the attack scenario the paper addresses.","marker":"[26]"},{"why":"Defines the QUIC handshake and the original RETRY packet and token structure that QFAM modifies.","marker":"[11]"},{"why":"Provides the Retry token layout that QFAM's enhanced token is designed to remain compatible with.","marker":"[22]"},{"why":"The open-source QUIC implementation that the authors modified on both client and server to implement and test QFAM.","marker":"[1]"}],"fun_headline_variants":["Proof-of-work RETRY token flips QUIC flood cost","Crypto challenge in RETRY token defeats QUIC floods","QUIC RETRY token gets a puzzle to block handshake floods","Puzzle-based RETRY token kills QUIC CPU amplification","QUIC handshake floods neutralized by crypto challenges"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole mitigation depends on the server correctly deciding when a flood is happening: the cryptographic challenges are only issued when the server's unspecified detector flips into mitigation mode, so a missed attack leaves the server as exposed as before and a false alarm makes every legitimate client pay puzzle cost for no benefit.","fun_headline_variants_meta":{"raw":{"variants":["Proof-of-work RETRY token flips QUIC flood cost","Crypto challenge in RETRY token defeats QUIC floods","QUIC RETRY token gets a puzzle to block handshake floods","Puzzle-based RETRY token kills QUIC CPU amplification","QUIC handshake floods neutralized by crypto challenges"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000146,"raw_usage":{"total_tokens":1153,"prompt_tokens":884,"completion_tokens":269,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":500,"completion_tokens_details":{"reasoning_tokens":186}},"tokens_in":500,"tokens_out":269,"duration_ms":3387,"temperature":1.0,"reasoning_tokens":186,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T17:21:45.144273+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the paper's one-server, two-client testbed with an intentionally flawed detector, e.g., a fixed threshold that misses a slow ramp-up of handshake requests, and show that a moderate flood below the threshold still drives server CPU to saturation because no challenges are issued; or, on the calculation side, show that at maximum difficulty the expected client solve time is so low that a botnet with many cores can still sustain an attack rate that exhausts the server.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Establishes the vulnerability QFAM targets by measuring a CPU amplification factor of up to 4.6 for QUIC handshake flooding relative to TCP."},{"cited_title":"Schmidt, and Matthias Wählisch","cited_arxiv_id":null,"evidence_quote":"Shows that address validation is often disabled in real QUIC deployments, motivating the attack scenario the paper addresses."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the Retry token layout that QFAM's enhanced token is designed to remain compatible with."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The open-source QUIC implementation that the authors modified on both client and server to implement and test QFAM."}],"review_version":1}