{"id":"16bc5e32-3f4b-42bd-bd34-2f46c9dd4fdc","arxiv_id":"2607.12765","paper_version":1,"verdict":"CONDITIONAL","confidence":"LOW","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A cloud-orchestrated multi-domain QKD architecture with SDN and PQC enables quantum-safe key transport across heterogeneous vendor and non-QKD domains on a real testbed.","lead":"The paper describes a multi-domain quantum-secure network that combines vendor-agnostic QKD, SDN orchestration, cloud trust services, and post-quantum cryptography for Zero Trust access. It matters because it aims to make quantum-safe key transport work across mixed infrastructures that do not all have native QKD.","discovery_kind":"new_application","skeptic_critique":{"model":"grok-4.5","headline":"Abstract-only review leaves the central multi-vendor testbed claim uncheckable; the load-bearing generalization of low overhead and QKD-key bottleneck cannot be verified without methods, numbers, or baselines.","rationale":"The Reader correctly flags that the abstract alone cannot establish soundness or generalizability of the multi-vendor testbed results. My concern is identical: the architecture claim is plausible systems work, but every quantitative assertion (low PQC/SDN overhead, QKD retrieval as bottleneck, successful extension beyond native QKD) is unsupported without the missing methods, tables, and figures. No internal contradiction can be diagnosed from the abstract; the issue is purely evidentiary. Therefore the CONDITIONAL verdict with LOW confidence is appropriate and needs no adjustment. Agreement with the Reader is full on the weakest assumption (generalization from an underspecified testbed). A concrete next step is simply to inspect the full paper’s experimental section for the missing numbers and baselines; until then the claim stays provisional.","tokens_in":1984,"tokens_out":538,"duration_ms":5120,"concrete_test":"Obtain the full paper (or supplementary material) and extract the quantitative results for PQC/SDN overhead and QKD key-retrieval latency across the three vendors and non-QKD domains; recompute relative overhead against an explicit classical or single-vendor baseline under stated load. If absolute numbers, baselines, or failure/trust conditions are missing or show overhead >10-20% or non-generalizable bottlenecks, the headline claim weakens and the CONDITIONAL verdict should move toward REJECT or remain pending.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim rests on a real multi-domain testbed (three QKD vendors + non-QKD domains) showing that PQC/SDN overhead stays relatively low and that the main bottleneck is QKD key retrieval / vendor-specific streaming, thereby extending quantum-safe key transport beyond native QKD boundaries under Zero Trust multi-level PQC authentication. Because only the abstract is available, none of the supporting evidence is inspectable: no topology, no key rates or latencies, no device constraints, no threat model, no quantitative baselines, no duration or load conditions, and no comparison against non-PQC or single-vendor controls. The weakest link is therefore not an internal inconsistency but the complete absence of the empirical material that would make the generalization from testbed to production multi-domain networks load-bearing. Without those data the claim that overhead is low and that the architecture successfully bridges heterogeneous domains remains an untested assertion rather than a demonstrated result.","agreement_with_reader":"agree"},"referee_report":{"model":"grok-4.5","summary":"The manuscript proposes a multi-domain, multi-site quantum-secure network architecture that integrates vendor-agnostic QKD, SDN orchestration, and cloud-managed trust services. Communication is based on Zero Trust Network Access with multi-level authentication using post-quantum cryptography (PQC) signature and key-encapsulation algorithms. The system is reported to have been deployed on a real-world testbed that includes QKD nodes from three vendors as well as domains without QKD infrastructure. The abstract asserts that experimental results show PQC and SDN overhead remain relatively low even on constrained devices, that the main bottleneck is QKD key retrieval and vendor-specific key streaming, and that the framework thereby extends quantum-safe key transport beyond native QKD boundaries while preserving interoperability and compatibility with existing infrastructures.","tokens_in":2226,"tokens_out":952,"duration_ms":17908,"significance":"If the experimental claims hold under transparent methods and realistic conditions, the work would address a genuine operational gap: scaling QKD across heterogeneous vendors, administrative domains, and non-QKD segments via SDN and PQC-based Zero Trust. Demonstrating multi-vendor interoperability and identifying QKD key retrieval—not PQC or SDN—as the dominant bottleneck would be of practical value to operators and standards efforts. The explicit treatment of non-QKD domains and multi-level PQC authentication is a useful design contribution. Significance, however, depends entirely on the quality of the evaluation (topology, metrics, baselines, threat model, load and failure conditions), none of which can be assessed from the abstract alone.","major_comments":[{"comment":"The load-bearing empirical claims—that PQC and SDN overhead remain 'relatively low' and that 'the main bottleneck [is] QKD key retrieval and vendor-specific key streaming'—are unsupported by any quantitative evidence in the available text. No latencies, key rates, overhead percentages, device constraints, topology or scale, duration, load conditions, error bars, or baselines (e.g., classical, single-vendor, or non-PQC controls) are given. Without these, the generalization from the reported three-vendor testbed to production multi-domain networks cannot be evaluated. Full methods and results with reproducible metrics are required before the central claim can be accepted.","section":"Abstract"},{"comment":"The security claim that the architecture extends 'quantum-safe key transport beyond native QKD boundaries' under Zero Trust multi-level PQC authentication is load-bearing but underspecified. The abstract does not name the PQC algorithms, describe how multi-level authentication is composed across administrative domains, define the trust model for cloud-managed services, or address key compromise, node failure, or partial QKD availability. These design and threat-model details must be stated and argued for the security contribution to be assessable.","section":"Abstract"},{"comment":"Vendor-agnostic QKD integration across three vendors is a core contribution, yet the abstract gives no indication of the abstraction layer or interfaces used, nor how vendor-specific key-streaming limitations were measured or mitigated. Concrete interface specifications and comparative measurements are needed to substantiate interoperability and the bottleneck attribution.","section":"Abstract"}],"minor_comments":[{"comment":"Qualitative phrases such as 'relatively low' and 'main bottleneck' would be more informative even in an abstract if accompanied by order-of-magnitude figures or percentage ranges.","section":"Abstract"},{"comment":"'Zero Trust Network Access protocols' and 'cloud-managed trust services' are named without a brief indication of the concrete protocols or services; a short clarification would improve accessibility.","section":"Abstract"},{"comment":"The claim of 'compatibility with existing infrastructures' does not identify which infrastructures or standards (e.g., ETSI QKD APIs, specific SDN controllers) were targeted.","section":"Abstract"}],"recommendation":"uncertain","confidential_remarks":"Only the abstract was available for this review; a definitive recommendation is not possible without the full manuscript (methods, results, threat model, and evaluation details). If the full paper supplies quantitative multi-vendor measurements with clear baselines and a stated threat model, the work may be suitable for major or minor revision at a systems/security venue; if those materials are thin, rejection for insufficient evidence would be appropriate. Please provide the full text for a complete review."},"author_rebuttal":null,"desk_editor":{"model":"grok-4.5","letter":"The one thing you need to know: this is a systems architecture paper claiming a multi-domain QKD network that stitches three vendors plus non-QKD sites via SDN orchestration, cloud trust services, and Zero Trust with PQC auth. The punchline is that PQC/SDN overhead stays relatively low and the real bottleneck is QKD key retrieval and vendor-specific streaming. That is a useful operator-facing result if the numbers hold, not a new crypto primitive.\n\nWhat looks new and solid on the face of it is the multi-vendor real testbed claim and the explicit bridging of quantum-safe keys into domains that have no QKD hardware. Combining vendor-agnostic QKD interfaces, SDN control, and PQC-based multi-level authentication is legitimate systems work. The abstract is clear about the problem (interoperability, trusted nodes, administrative domains) and does not overclaim a first-principles breakthrough. Circularity risk is low; this is measurement of a built system, not a fitted derivation.\n\nThe soft spot is exactly what the stress-test says: we only have the abstract. No topology, key rates, latencies, load conditions, threat model, baselines, or comparison to single-vendor or non-PQC controls. So the generalization that overhead is low and that the architecture works under realistic multi-domain conditions is still an assertion. That is not a flaw in the argument structure; it is missing evidence. Confidence has to stay low until the full paper shows the numbers.\n\nWho it is for: people building or standardizing quantum-safe networks, SDN-QKD operators, and anyone who cares about multi-vendor interoperability rather than new QKD protocols. A serious referee should see the full methods and data. I would send it to peer review rather than desk-reject; the problem is real and the integration angle is concrete enough to deserve scrutiny. I would not cite it yet from the abstract alone, and I would only bring it to reading group if someone already works in this stack and wants to dig into the testbed details once available.","headline":"Abstract-only systems paper on multi-vendor QKD + SDN + PQC; plausible integration claim, but the testbed evidence is uncheckable from what we have.","tokens_in":2822,"tokens_out":520,"would_cite":false,"duration_ms":5043,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"grok-4.5","headline":"A multi-domain quantum-secure network integrates vendor-agnostic QKD, SDN orchestration, and PQC-based Zero Trust to extend quantum-safe keys past native QKD boundaries.","keywords":["quantum key distribution","QKD networks","post-quantum cryptography","software-defined networking","zero trust","multi-domain networks","cloud orchestration","vendor interoperability"],"falsifier":"Run sustained multi-domain key-delivery sessions with concurrent clients and deliberate vendor key-stream throttling on the same architecture; if PQC or SDN overhead then dominates latency or cross-domain key transport fails, the claim that QKD retrieval is the sole main bottleneck and that the design cleanly extends quantum-safe keys does not hold.","tokens_in":2890,"feed_emoji":"🔐","tokens_out":964,"duration_ms":16768,"temperature":0.7,"pith_summary":"This paper tries to establish that a cloud-orchestrated, service-oriented architecture can make quantum key distribution usable across heterogeneous multi-domain, multi-site networks that mix equipment from different vendors and domains with no QKD at all. It unifies vendor-agnostic QKD interfaces, software-defined networking for orchestration, and cloud-managed trust services under Zero Trust Network Access that relies on post-quantum signature and key-encapsulation algorithms for multi-level authentication. A sympathetic reader would care because today’s QKD deployments are hampered by vendor-specific interfaces, trusted-node constraints, and poor interoperability; if the architecture works, operators can carry quantum-safe keys farther without rebuilding existing infrastructure. On a real testbed spanning three QKD vendors plus non-QKD domains the authors report that PQC and SDN overhead stay relatively low even on constrained devices, while the dominant bottlenecks are QKD key retrieval and vendor-specific key streaming. The framework therefore claims to extend quantum-safe key transport beyond native QKD coverage while remaining flexible and compatible with what already exists.","feed_headline":"Cloud-orchestrated QKD network spans three vendors and non-QKD domains","feed_subtitle":"PQC Zero Trust and SDN keep overhead low while pushing quantum-safe keys past native QKD edges.","key_machinery":"The central mechanism is a cloud-orchestrated, service-oriented multi-domain architecture that presents vendor-agnostic QKD interfaces under SDN control and protects the trust plane with PQC-based Zero Trust multi-level authentication, thereby allowing key material to cross from QKD-equipped domains into ordinary network domains.","core_discovery":"A flexible multi-domain multi-site quantum-secure network can be realized by integrating vendor-agnostic QKD, SDN orchestration and cloud-managed trust services, with Zero Trust multi-level authentication built on PQC algorithms; the design extends quantum-safe key transport beyond native QKD boundaries while keeping PQC and SDN overhead low relative to the QKD key-retrieval bottleneck, as shown on a real testbed that includes three QKD vendors and non-QKD domains.","pith_inferences":["The same cloud-managed trust plus SDN pattern could later be applied to other hybrid classical-quantum services such as entanglement distribution or quantum sensing networks.","Standardized vendor key-streaming APIs will be required before the reported overhead advantage remains true under sustained multi-tenant production load.","Pairing PQC for authentication with QKD for key material offers a concrete migration path for organizations that cannot wait for full QKD coverage.","A natural next measurement is end-to-end key-delivery latency and success rate under concurrent multi-domain sessions that stress the claimed bottleneck."],"forward_implications":["Quantum-safe keys can be delivered into administrative domains that contain no QKD hardware.","Operators can mix QKD equipment from multiple vendors without writing pair-wise custom integrations.","PQC authentication can protect the control and trust plane without becoming the dominant latency source on constrained devices.","Existing classical infrastructure remains usable because the design preserves interoperability rather than requiring wholesale replacement.","The practical scaling limit of multi-domain QKD shifts from orchestration overhead to key-generation rates and vendor streaming APIs."],"fun_headline_variants":["Multi-vendor QKD spans domains via SDN cloud and PQC Zero Trust","Cloud SDN pushes quantum keys across three vendors and non-QKD sites","Vendor-agnostic QKD network unifies multi-domain quantum-safe transport","PQC-backed Zero Trust extends QKD keys beyond native infrastructure edges","Testbed shows low SDN-PQC overhead vs QKD key retrieval bottleneck"],"cache_read_input_tokens":128,"weakest_assumption_plain":"Results from one real-world testbed with three QKD vendors and some non-QKD domains will generalize to production multi-domain networks under realistic load, trust and failure conditions.","fun_headline_variants_meta":{"raw":{"variants":["Multi-vendor QKD spans domains via SDN cloud and PQC Zero Trust","Cloud SDN pushes quantum keys across three vendors and non-QKD sites","Vendor-agnostic QKD network unifies multi-domain quantum-safe transport","PQC-backed Zero Trust extends QKD keys beyond native infrastructure edges","Testbed shows low SDN-PQC overhead vs QKD key retrieval bottleneck"]},"model":"grok-4.5","effort":"low","cost_usd":0.00513,"raw_usage":{"total_tokens":1391,"prompt_tokens":756,"num_sources_used":0,"completion_tokens":102,"cost_in_usd_ticks":51300000,"prompt_tokens_details":{"text_tokens":756,"audio_tokens":0,"image_tokens":0,"cached_tokens":128},"completion_tokens_details":{"audio_tokens":0,"reasoning_tokens":533,"accepted_prediction_tokens":0,"rejected_prediction_tokens":0}},"tokens_in":756,"tokens_out":102,"duration_ms":4068,"temperature":1.0,"reasoning_tokens":533,"cache_read_input_tokens":128,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-15T03:31:08.312065+00:00","model_set":{"reader":"grok-4.5"},"falsifier":"Run sustained multi-domain key-delivery sessions with concurrent clients and deliberate vendor key-stream throttling on the same architecture; if PQC or SDN overhead then dominates latency or cross-domain key transport fails, the claim that QKD retrieval is the sole main bottleneck and that the design cleanly extends quantum-safe keys does not hold.","supporting_citations":[],"review_version":1}