DFE cryptographic standard

DFE targets the NSA Commercial National Security Algorithm (CNSA) family, because national-security deployment is in scope, while remaining deployable in ordinary commercial environments. The user base is small and high-value, so algorithm strength is chosen for compliance rather than throughput.

Precise naming matters here. DFE's symmetric and hash primitives are at CNSA 2.0; its asymmetric primitives (key establishment and signatures) are the CNSA 1.0 classical suite (the Suite B successor), which is what CNSA 2.0 is migrating away from. So the accurate description is: a CNSA 1.0-aligned classical baseline, with AES-256/SHA-384 already meeting CNSA 2.0, a hybrid post-quantum key-exchange layer enabled on the wire today, and a documented migration to full CNSA 2.0 (ML-KEM-1024, ML-DSA-87). We deliberately do not label a P-384/ES384 baseline "CNSA 2.0" - that suite's whole purpose is post-quantum, and P-384/ES384 are not on its algorithm list.

This document covers the deployment layer: transport (TLS), certificates, and data at rest. Application signing (the ES384 JWT) is covered by the engine's auth topology document (AUTH-ENVOY-TOPOLOGY.md).

What "CNSA" means here - the honest map

Function	DFE today	CNSA 1.0	CNSA 2.0	Status
Symmetric	AES-256-GCM	AES-256	AES-256	CNSA 2.0
Hash	SHA-384	SHA-384	SHA-384 / 512	CNSA 2.0
Key establishment	ECDH P-384 + hybrid ML-KEM on the wire	ECDH P-384	ML-KEM-1024	CNSA 1.0 classical; hybrid PQC in transit
Signatures (certs, JWT)	ECDSA / ES384 P-384	ECDSA P-384	ML-DSA-87	CNSA 1.0 classical
Firmware signing	n/a	-	LMS / XMSS	not in scope

The residual quantum exposure is therefore precisely the asymmetric layer: harvest-now-decrypt-later against the key-exchange (mitigated today by the hybrid ML-KEM transport layer below) and forge-later against long-lived signing keys and roots (mitigated by short lifetimes + crypto-agility until ML-DSA is deployable).

Profiles

DFE ships two profiles; a deployment selects one and every component inherits its floor.

Layer	prod (default, commercial-safe)	highsec (national-security)
TLS floor	1.2 minimum, 1.3 preferred	1.3 only
Symmetric	AES-256-GCM	AES-256-GCM
Hashing	SHA-384	SHA-384 / SHA-512
Certificates / signatures	ECDSA P-384, SHA-384	ECDSA P-384 -> ML-DSA-87
Key establishment	ECDHE P-384 + hybrid ML-KEM where offered	hybrid ML-KEM required, ML-KEM-1024 target
SSH	Ed25519, ML-KEM hybrid KEX	Ed25519, ML-KEM hybrid KEX

prod is the corporate default. Its TLS 1.2 floor is deliberate: TLS 1.3 is universal in modern browsers, but 1.3-only breaks a long tail of enterprise middleboxes and legacy API clients, so prod requires 1.2 as a floor (removing SSLv3/TLS 1.0/1.1) with 1.3 preferred, and holds AES-256-GCM at the 1.2 layer via an explicit cipher list. highsec raises the floor to TLS 1.3-only. Both offer hybrid post-quantum key exchange where the peer supports it.

The design is crypto-agile: protocol floors, curves, cipher policy and signing algorithms are configuration, not code, so raising a profile or adopting a PQC primitive is a config change.

Transport (TLS)

• Edge. The single Envoy front layer terminates TLS (1.2 floor in prod, 1.3-only in highsec), offers TLS_AES_256_GCM_SHA384 (with ECDHE-ECDSA-AES256-GCM-SHA384 at the 1.2 layer), and negotiates ECDHE on P-384. It also offers the hybrid X25519MLKEM768 group (a TLS 1.3 group; see the migration section) so a post-quantum-capable client gets PQC key agreement, with classical clients falling back to P-384 - no protocol break.
• Backing services. ClickHouse, Kafka, the metadata store and the telemetry pipeline speak TLS with certificates issued by the internal certificate authority. Broker authentication is SASL over TLS using SCRAM-SHA-512.
• Federation. Outbound connections to external OIDC identity providers use TLS and verify the provider's certificate, but negotiate whatever cipher and group the provider supports - the federation leg does not require CNSA ciphers, so interoperability with Google, Okta, Entra ID and ADFS is preserved.

Managed-service caveat

Where a deployment fronts DFE with a managed load balancer or CDN (AWS ALB/CloudFront, Azure, GCP), TLS policy is a named bundle, not an a-la-carte suite - the closest policy usually also admits AES-128 and P-256. DFE's own Envoy edge expresses the suite exactly; a managed front cannot. Deployments that use one MUST pin the specific named policy and record the deltas from this standard rather than assume a clean suite. Cloud KMS offers ECC P-384 for signing/mTLS but no ML-KEM/ML-DSA keys yet, which is part of why the asymmetric layer stays classical for now.

Certificates

• Leaf and CA certificates: ECDSA on the P-384 curve (CNSA 1.0 classical), signed with SHA-384. Applies to the front-door wildcard certificate, the internal CA, and every in-cluster service certificate.
• Issuance: cert-manager issues in-cluster certificates from the P-384 internal CA; public certificates come from the ACME issuer.
• Lifetime and agility: certificates are short-lived and auto-rotated. Pinning is deliberately avoided so the signature algorithm can advance (P-384 today, ML-DSA-87 when deployable) without re-pinning clients. Short lifetimes are the forge-later mitigation until ML-DSA is available.

Data at rest

• Secrets are held in the secrets backend (OpenBao under Kubernetes; an encrypted file store in the single-container profile) and never written to disk in the clear. Any local secret cache is sealed with AES-256-GCM.
• Signing keys. The JWT signing private key is AES-256 wrapped at rest and released through the secrets seam.
• Randomness. Key material and tokens come from a CSPRNG at 256-bit strength or above.

Hashing

SHA-384 is the DFE hash standard (SHA-512 equally acceptable); broker credential hashing uses SCRAM-SHA-512. Password verification uses a work-hard KDF (bcrypt). SHA-1 and MD5 are not used for any security purpose; where a downstream system mandates a specific hash for non-security addressing (for example ClickHouse row identity), that use is isolated from confidentiality and integrity.

Tokens (JWT)

The JWT signature is ES384 (ECDSA P-384 + SHA-384) - a deliberate, dated decision to stay classical: ML-DSA in JOSE is still draft-stage with thin library support, and an ML-DSA signature is far larger than a header/cookie budget allows. ES384 is verifiable across the whole chain (Envoy jwt_authn, PyJWT, Node jose). Two enforcement rules matter more than the curve:

• The accepted algorithm is allow-listed to ES384 only server-side. The classic JWT breaks are alg:none and RS/HS confusion, not the curve.
• ECDSA signing uses RFC 6979 deterministic-k (or a vetted library) - nonce reuse, not the curve choice, is ECDSA's failure mode.

Post-quantum migration - the path to full CNSA 2.0

CNSA 2.0's asymmetric end-state is ML-KEM-1024 (FIPS 203) for key establishment and ML-DSA-87 (FIPS 204) for signatures.

• Key establishment (live today). DFE offers the hybrid X25519MLKEM768 group at the edge, which ships in mainstream TLS stacks (Chrome, Firefox, OpenSSL 3.5, Go 1.24, BoringSSL/aws-lc-rs) and gives real harvest-now-decrypt-later protection with no custom code. Two honest caveats: its post-quantum strength is ML-KEM-768 (NIST level 3), below CNSA 2.0's ML-KEM-1024; and its classical half is X25519, not a NIST curve. The CNSA-pure hybrid is SecP384r1MLKEM1024 (P-384 + ML-KEM-1024), which is specified but has far thinner deployment. DFE's conscious choice is to enable the widely-interoperable X25519MLKEM768 now for actual on-the-wire PQC protection, and to add SecP384r1MLKEM1024 as the preferred group once BoringSSL/Envoy support it - the key-exchange group is a config value, so this is a one-line change.
• Signatures (roadmap). ES384 is current across the chain. ML-DSA-87 replaces it once its JOSE binding standardises and the verifiers (Envoy, server and browser libraries) support it. kid-tagged keys + config-driven alg make this a rotation, not a rewrite.

Enforcement - policy-as-code, not prose

This standard is enforced in CI, not aspired to in a wiki. The deployment pipeline gates on policy checks (conftest / checkov / tfsec over the helm + terraform + ArgoCD manifests) so drift fails the build: every TLS listener sets the profile floor, at-rest encryption is AES-256, and the internal mTLS profile is a P-384 chain. A change that weakens the suite does not merge.

References

• NSA CNSA 1.0 (Suite B successor) and NSA CNSA 2.0 FAQ
• AUTH-ENVOY-TOPOLOGY.md (engine auth docs) - the ES384 JWT signing side.
• FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 197 (AES), FIPS 180-4 (SHA-2); draft-ietf-tls-ecdhe-mlkem (hybrid groups).