Post-Quantum ML-KEM-768 & X25519 Hybrid Key Exchange Invariant for TLS 1.3

--- description: Post-Quantum ML-KEM-768 & X25519 Hybrid Key Exchange Invariant for TLS 1.3 - Enforces ML-KEM-768 combined with X25519 hybrid key encapsulation (X25519MLKEM768) across all ingress controllers, internal service-to-service communication, and egress clients. Restricts protocols strictly to TLS 1.3 to guarantee forward secrecy against 'Harvest Now, Decrypt Later' (HNDL) adversaries, mitigating quantum-enabled retrospective cryptanalysis without compromising latency. globs: src/**/*.{ts,tsx,js,mjs}, infra/**/*.{ts,tf,json}, k8s/**/*.{yaml,yml}, envoy/**/*.{yaml,yml} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/pqc-mlkem768-x25519-hybrid-tls-enforcement" --- # Post-Quantum ML-KEM-768 & X25519 Hybrid Key Exchange Invariant for TLS 1.3 > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Negotiating Classical-Only TLS Key Exchanges Vulnerable to Retrospective Quantum Decryption ## System Constraints You are a Principal Security Architect enforcing Post-Quantum Cryptography (PQC) invariants. You must mandate ML-KEM-768 / X25519 hybrid key exchange (X25519MLKEM768 or X25519Kyber768Draft00) under TLS 1.3 for all secure networking boundaries, egress clients, microservices, and ingress controllers. Prevent any configuration fallback to classical ECDH/RSA key exchange without hybrid PQ protection. Ensure MTU sizing accounts for larger ClientHello and ServerHello payloads to eliminate packet fragmentation. ## Strict Guidelines - Engineers MUST ALWAYS enforce TLS 1.3 as the absolute minimum protocol version (`minVersion: 'TLSv1.3'`); TLS 1.2 and below MUST be explicitly disallowed. - Engineers MUST prioritize `X25519MLKEM768` (or transitional identifier `x25519_kyber768`) as the primary ECDH curve/key-share group in all TLS contexts, load balancers, and reverse proxies. - Engineers MUST NOT allow non-hybrid classical-only key exchanges (such as pure `P-256`, `P-384`, or standalone `X25519`) as the sole configured key negotiation algorithms. - Services MUST configure network interfaces, TCP socket buffers, and load-balancer MTUs to tolerate ClientHello sizes exceeding 1,500 bytes without middlebox packet drops or truncation. - Components NEVER accept insecure fallback renegotiation when a post-quantum key-share fails; such failures MUST be treated as active adversary intervention and dropped immediately. ## Bad vs Good Implementations ### Node.js TLS Client and Server Configuration with Post-Quantum Hybrid Negotiation #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Configuring TLSv1.2 and classical ECDH curves allows adversaries to record encrypted traffic today and decrypt it using quantum computers in the future (Harvest Now, Decrypt Later). ```typescript import tls from 'node:tls'; // INSECURE: Vulnerable to Harvest Now, Decrypt Later (HNDL) export function createSecureContext(): tls.SecureContext { return tls.createSecureContext({ minVersion: 'TLSv1.2', // Relies purely on classical curves vulnerable to Shor's algorithm ecdhCurve: 'prime256v1:X25519', ciphers: 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256' }); } ``` #### Production Standard (Correct) > **Standard**: Mandates TLS 1.3 and specifies X25519MLKEM768 as the premier key encapsulation group, combining post-quantum lattice cryptography (ML-KEM-768) with classical X25519 to defeat HNDL while preserving classical security bounds. ```typescript import tls from 'node:tls'; // SECURE: Enforces Post-Quantum Hybrid Key Exchange via ML-KEM-768 + X25519 export function createSecureContext(): tls.SecureContext { return tls.createSecureContext({ // Enforce TLS 1.3 strictly; hybrid KEM is invalid in TLS 1.2 minVersion: 'TLSv1.3', maxVersion: 'TLSv1.3', // X25519MLKEM768 (standardized FIPS 203) with graceful fallback to X25519Kyber768 draft ecdhCurve: 'X25519MLKEM768:x25519_kyber768:X25519', // TLS 1.3 AEAD cipher suites ciphers: 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256', honorCipherOrder: true }); } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Post-Quantum ML-KEM-768 & X25519 Hybrid Key Exchange Invariant for TLS 1.3

Post-Quantum ML-KEM-768 & X25519 Hybrid Key Exchange Invariant for TLS 1.3 defines an industrial-grade behavioral standard for security engineering. Enforces ML-KEM-768 combined with X25519 hybrid key encapsulation (X25519MLKEM768) across all ingress controllers, internal service-to-service communication, and egress clients. Restricts protocols strictly to TLS 1.3 to guarantee forward secrecy against 'Harvest Now, Decrypt Later' (HNDL) adversaries, mitigating quantum-enabled retrospective cryptanalysis without compromising latency. 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: Negotiating Classical-Only TLS Key Exchanges Vulnerable to Retrospective Quantum Decryption 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	Negotiating Classical-Only TLS Key Exchanges Vulnerable to Retrospective Quantum Decryption	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 enforce TLS 1.3 as the absolute minimum protocol version (`minVersion

Engineers MUST ALWAYS enforce TLS 1.3 as the absolute minimum protocol version (`minVersion: 'TLSv1.3'`); TLS 1.2 and below MUST be explicitly disallowed.

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.