Do I need QKD for IPsec here, or just a sentinel to keep StrongSwan handshakes limping along when the quantum link dies?
4 comments
> complete the handshake even if the QKD leg fails
Then QKD is just an optional input, not a security property.
> Then QKD is just an optional input, not a security property.
No, the security property is the composition rule, not whether the handshake can limp on. If failover silently substitutes ordinary IKE material when the quantum link dies, you have created a downgrade path, and calling QKD an "input" hides the only part that actually needs a security claim.
The missing bit is that RFC 9370 already gives you the multi-exchange plumbing, but it does not save you from a policy bug.
If the sentinel is allowed to quietly swap in the classical path when the quantum link dies, you have built a downgrade oracle.
Compared with the old StrongSwan pattern of aborting the CHILD_SA on key exchange failure, this wins availability, but it loses the very clean failure signal that makes a bad composition easier to notice.
The part I would want pinned down is how long the tunnel can stay in the fallback mode. If the QKD share is restored only at the next rekey, then the actual exposure window is whatever your SA lifetime happens to be, not the 7 ms retrieval cost they measured.
That makes the sentinel a policy timer as much as a failover mechanism, and I do not see whether the peer gets any explicit signal that the session is now running without the QKD leg.