Add Quantum-Safe Cryptography Requirements to MCP Security Paper

[imolloy]

Problem Statement

The current MCP Security paper comprehensively addresses cryptographic controls in sections 3.2.4, 3.2.6, and 3.2.7, but does not address the emerging threat posed by quantum computing to current cryptographic algorithms. As quantum
computing advances, the cryptographic foundations underlying MCP transport security (TLS, mutual authentication, integrity checks) will become vulnerable to quantum attacks.

Given that MCP is designed for long-term enterprise deployment and handles sensitive AI agent communications, the paper should provide forward-looking guidance on quantum-safe cryptography to ensure implementations remain secure as quantum
computing capabilities mature.

Proposed Solution

Add a new subsection 3.2.12 Quantum-Safe Cryptography that addresses:

Core Requirements

• Migration Planning: Organizations should develop timelines for transitioning to post-quantum cryptographic algorithms, aligned with NIST Post-Quantum Cryptography standards (FIPS 203, 204, 205)
• Hybrid Approaches: During the transition period, implement hybrid cryptographic schemes that combine classical and post-quantum algorithms to maintain security against both classical and quantum attacks
• Algorithm Selection: Prioritize NIST-standardized post-quantum algorithms:
  • Key Exchange: ML-KEM (Module Lattice-based Key Encapsulation Mechanism)
  • Digital Signatures: ML-DSA (Module Lattice-based Digital Signature Algorithm) and SLH-DSA (Stateless Hash-based Digital Signature Algorithm)

MCP-Specific Considerations

• Transport Layer: Update TLS configurations to support post-quantum cipher suites for HTTP streaming transport
• Cryptographic Verification: Ensure post-quantum digital signatures are supported for resource verification (section 3.2.6)
• Remote Attestation: Plan migration of TEE attestation mechanisms to quantum-safe algorithms (section 3.2.4)

Risk Assessment Integration

This addition would enhance the mitigation strategies for existing threat categories:

• MCP-T7: Session and Transport Security Failures - quantum attacks on TLS
• MCP-T6: Missing Integrity/Verification Controls - quantum attacks on digital signatures
• MCP-T11: Supply Chain and Lifecycle Security Failures - quantum-vulnerable cryptographic dependencies

Justification

1. Timeline Urgency: NIST recommends organizations begin post-quantum transitions now, with completion by 2035
2. Enterprise Scope: The paper's enterprise focus requires addressing long-term cryptographic sustainability
3. MCP Longevity: MCP deployments may operate for decades, spanning the quantum threat timeline
4. Standards Alignment: Aligns with NIST Post-Quantum Cryptography standards published in 2024

Implementation Notes

• Position as section 3.2.12 after Lifecycle and Governance
• Cross-reference with existing cryptographic sections (3.2.4, 3.2.6, 3.2.7)
• Update Table of Contents and threat mitigation mappings
• Consider adding a new threat category for quantum-specific risks if warranted

References for Content Development

• NIST Special Publication 800-208: "Recommendation for Stateful Hash-Based Signature Schemes"
• NIST Post-Quantum Cryptography Standards (FIPS 203, 204, 205)
• RFC 9242: "Hybrid Post-Quantum Key Encapsulation Methods"
• NSA Commercial Solutions for Classified (CSfC) Quantum-Safe Capability Packs

[jagmarques]

Good proposal. One practical consideration: the hybrid approach (classical + post-quantum) adds non-trivial overhead to handshakes. For MCP transport specifically, where agents may open many short-lived connections, documenting expected latency impact of ML-KEM hybrid key exchange would help implementors plan capacity.

Also worth cross-referencing CNSA 2.0 timelines alongside NIST, since enterprise MCP deployments in defense/government contexts may have stricter migration deadlines than 2035.

[parmarmanojkumar]

Triage update (2026-04-15)

Summary:
Proposal to add post-quantum cryptography requirements; thread includes practical performance concerns for hybrid handshakes.

Type:
conceptual

Recommendation:
Accept - separate track

Proposed wave:
Later conceptual track

Proposed milestone/versioning:
mcp-security-whitepaper-v2-research

Proposed labels/tags:
help wanted, whitepaper, v2 branch

Related/dependencies: #24, #35

Reasoning:
Important medium-term topic; keep as scoped research/addendum track with explicit cost/performance guidance before normative inclusion.

[Johncavanaugh-IIS]

Ian we are working on PQC solutions as well. Is there a CoSAI information classification spec or resource might leverage? Data flowing through MCP services or servers will need to be TLS1.3 ready as well as the other network and server hops from end to end? Long lived data is the critical classification (think DNA, fingerprint, health and certain corporate records ) that need to identified and then controlled though transmission for point a to b.

[sarahnovotny]

Status update — WS4 Apr 23

@Johncavanaugh-IIS reported that PQC addendum work was delayed by a product release this cycle but is committed to land before the Apr 30 meeting. Scope per the Apr 23 readout: data classification, algorithms, and ciphers for data flowing through MCP services.

Open question still on the table from John's Apr 16 comment above: is there a CoSAI information-classification spec or resource the addendum can leverage? If anyone has pointers, please reply here so we don't reinvent the framing.