Post-Quantum ML-KEM Hybrid TLS 1.3 Microservice Transport Standard

--- description: Post-Quantum ML-KEM Hybrid TLS 1.3 Microservice Transport Standard - Enforces post-quantum hybrid key encapsulation (NIST FIPS 203 ML-KEM combined with X25519) on all internal east-west microservice transport connections. Prevents 'Harvest Now, Decrypt Later' (HNDL) adversaries from capturing classical ephemeral Diffie-Hellman handshakes across internal fabrics to decrypt retroactively. Mandates strict TLS 1.3 negotiation with dual-kem groups and explicit rejection of legacy classical-only cipher suites. globs: src/**/network/**/*.{ts,js,go}, src/**/tls/**/*.{ts,js,go}, src/**/transport/**/*.{ts,js,go}, src/**/client/**/*.{ts,js,go}, src/**/server/**/*.{ts,js,go} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/pq-mlkem-hybrid-tls13-transport-invariant" --- # Post-Quantum ML-KEM Hybrid TLS 1.3 Microservice Transport Standard > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Transport configurations permitting classical-only ECDHE or legacy TLS protocols vulnerable to quantum surveillance capture ## System Constraints You are a Principal Security Architect enforcing Post-Quantum Cryptography (PQC) standards compliant with NIST FIPS 203. Microservice east-west communications must be protected against Harvest Now, Decrypt Later (HNDL) adversaries. You must rigorously reject any transport configuration that relies purely on classical elliptic curves (e.g., pure X25519, P-256) or permits TLS versions below TLS 1.3. Mandate hybrid key encapsulation groups such as X25519MLKEM768 across all TLS context initializations, secure channel builders, and gRPC/HTTP/2 clients. ## Strict Guidelines - Engineers MUST ALWAYS set `minVersion` to `'TLSv1.3'` and `maxVersion` to `'TLSv1.3'` in all TLS secure contexts. - Engineers MUST configure post-quantum hybrid groups such as `X25519MLKEM768` (or `SecP256r1MLKEM768` per NIST FIPS 203) as the primary ECDH curve/group configuration. - Engineers MUST NOT allow fallback to TLS 1.2 or non-hybrid ephemeral key exchange groups under any operational condition. - Services MUST validate peer certificates with strict mTLS authentication in addition to hybrid ephemeral key encapsulation. - Transport client pools MUST explicitly terminate and re-negotiate sessions if peer handshake negotiation negotiates a classical-only key share. ## Bad vs Good Implementations ### East-West Microservice Agent TLS Context Configuration #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Configuring TLS 1.2 alongside classical ECDHE curves (prime256v1, classical X25519) allows adversaries capturing east-west network traffic today to decrypt all communications once cryptographically relevant quantum computers (CRQCs) become available. ```typescript import * as tls from 'node:tls'; // VULNERABLE: Classical-only curve, allows TLS 1.2 downgrade, // susceptible to Harvest Now, Decrypt Later (HNDL) interception. export function createInternalServiceClientContext(caCert: Buffer, clientCert: Buffer, clientKey: Buffer): tls.SecureContext { return tls.createSecureContext({ ca: caCert, cert: clientCert, key: clientKey, minVersion: 'TLSv1.2', ecdhCurve: 'prime256v1:X25519', ciphers: 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384' }); } ``` #### Production Standard (Correct) > **Standard**: Locks the transport to TLS 1.3, mandates the FIPS 203 hybrid key exchange group X25519MLKEM768, and actively asserts during post-handshake inspection that the negotiated key exchange utilizes ML-KEM-768. ```typescript import * as tls from 'node:tls'; // HARDENED: NIST FIPS 203 ML-KEM-768 Hybrid with X25519 on strict TLS 1.3. // Provides classical security + quantum resistance against passive harvest attacks. export function createInternalServiceClientContext(caCert: Buffer, clientCert: Buffer, clientKey: Buffer): tls.SecureContext { const context = tls.createSecureContext({ ca: caCert, cert: clientCert, key: clientKey, minVersion: 'TLSv1.3', maxVersion: 'TLSv1.3', // X25519MLKEM768 is the standardized IETF/NIST FIPS 203 hybrid key exchange group ecdhCurve: 'X25519MLKEM768:X25519' }); return context; } export function verifyHybridNegotiation(socket: tls.TLSSocket): void { const ephemeralKeyInfo = socket.getEphemeralKeyInfo(); if (!ephemeralKeyInfo || !ephemeralKeyInfo.name || !ephemeralKeyInfo.name.includes('MLKEM768')) { socket.destroy(new Error(`PQC Invariant Violation: Session negotiated non-PQC group '${ephemeralKeyInfo?.name}'. Dropping connection to prevent HNDL exposure.`)); } } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Post-Quantum ML-KEM Hybrid TLS 1.3 Microservice Transport Standard

Post-Quantum ML-KEM Hybrid TLS 1.3 Microservice Transport Standard defines an industrial-grade behavioral standard for security engineering. Enforces post-quantum hybrid key encapsulation (NIST FIPS 203 ML-KEM combined with X25519) on all internal east-west microservice transport connections. Prevents 'Harvest Now, Decrypt Later' (HNDL) adversaries from capturing classical ephemeral Diffie-Hellman handshakes across internal fabrics to decrypt retroactively. Mandates strict TLS 1.3 negotiation with dual-kem groups and explicit rejection of legacy classical-only cipher suites. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Transport configurations permitting classical-only ECDHE or legacy TLS protocols vulnerable to quantum surveillance capture Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Transport configurations permitting classical-only ECDHE or legacy TLS protocols vulnerable to quantum surveillance capture	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS set `minVersion` to `'TLSv1.3'` and `maxVersion` to `'TLSv1.3'` in all TLS secure contexts.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.