Post-Quantum Cryptography Beyond TLS: Remain Quantum Safe

Key Takeaways

• Post-quantum cryptography (PQC) upgrades are necessary beyond TLS, encompassing protocols like SSH, IPsec, OpenPGP, and DNSSEC.
• OpenSSH versions 9.9 and above default to ML-KEM combined with X25519 ECDH, and versions 10.1+ actively warn users connecting to non-PQC servers.
• IPsec VPNs require updates to support composite keys (RFC9370) combining classic and post-quantum keys.
• DNSSEC faces significant PQC migration challenges due to signature size limits over UDP, potentially requiring Merkle tree ladders (MTL) to avoid packet fragmentation.

Affected Systems

• OpenSSH (versions prior to 9.9)
• IPsec VPNs
• DNSSEC infrastructure
• OpenPGP implementations
• Messaging Protocols (Signal, Apple Messages, MLS)

Attack Chain

Adversaries intercept and store encrypted network traffic (such as SSH, IPsec, or TLS) using classical cryptographic algorithms. This 'harvest now, decrypt later' strategy relies on the future availability of cryptographically relevant quantum computers to break asymmetric encryption (like RSA or Diffie-Hellman) and expose the stored plaintext data.

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: No
• Other Detection Logic: No

No specific detection rules are provided in the article, as the focus is on cryptographic standards and protocol upgrades rather than active malware detection.

Detection Engineering Assessment

EDR Visibility: Low — EDR tools typically do not inspect the specific cryptographic key exchange algorithms negotiated in network protocols like SSH or IPsec. Network Visibility: High — Network traffic analysis (NTA) and deep packet inspection can identify the key exchange algorithms negotiated during protocol handshakes (e.g., checking for ML-KEM or SNTRUP in SSH). Detection Difficulty: Moderate — Identifying legacy cryptographic algorithms requires network sensors capable of parsing SSH, TLS, and IKEv2 handshakes to extract key exchange parameters.

Required Log Sources

• Network flow logs
• Zeek/Suricata network logs

Hunting Hypotheses

Hypothesis	Telemetry	ATT&CK Stage	FP Risk
Identify SSH connections negotiating legacy (non-PQC) key exchange algorithms to prioritize server upgrades.	Network traffic logs (e.g., Zeek SSH analyzer)	Command and Control	Low

Control Gaps

• Lack of PQC support in legacy VPN concentrators
• Inability to inspect UDP-based DNSSEC signature sizes for PQC compliance without causing packet fragmentation

Key Behavioral Indicators

• SSH key exchange algorithms lacking 'mlkem' or 'sntrup'
• IKEv2 handshakes without composite key extensions (RFC9370)

False Positive Assessment

• Low

Recommendations

Immediate Mitigation

• Upgrade OpenSSH deployments to version 9.9 or higher to enable ML-KEM by default.

Infrastructure Hardening

• Audit IPsec VPN vendors for RFC9370 composite key support.
• Begin planning for DNSSEC algorithm rollovers and monitor IETF drafts for Merkle tree ladder (MTL) adoption.

User Protection

• Ensure mobile messaging applications are updated to versions supporting post-quantum protocols (e.g., Signal SPQR, Apple PQ3).

Security Awareness

• Educate engineering teams on the 'harvest now, decrypt later' threat model and the necessity of PQC beyond standard web TLS.

MITRE ATT&CK Mapping

• T1040 - Network Sniffing
• T1573 - Encrypted Channel

Additional IOCs

• Domains:
  • unsafe[.]example[.]com - Example domain used in the article to demonstrate OpenSSH warnings when connecting to a server without PQC support.
• Command Lines:
  • Purpose: Verify if the installed version of OpenSSH supports PQC key exchange algorithms (ML-KEM or SNTRUP). | Tools: ssh, egrep | Stage: Defense Evasion | ssh -Q kex | egrep