| Internet-Draft | Unheaded PQC Authentication | March 2026 |
| Bellis | Expires 20 September 2026 | [Page] |
This document specifies a post-quantum cryptographic (PQC) authentication mechanism for the Unheaded Protocol Foundation. It defines a multi-algorithm, dual-layer, tiered authentication architecture integrating three NIST PQC digital signature standards -- FIPS 205 (SLH-DSA), FIPS 204 (ML-DSA), and FIPS 206 (FN-DSA) -- plus two NIST PQC key-encapsulation mechanisms -- FIPS 203 (ML-KEM) and FIPS 207 (HQC) -- with the Monad wire format, Sophia BPF map dictionaries, and Wotan per-flow memory model.¶
Layer 1 (Wire-Level, REQUIRED): Full PQC signatures are stored in Sophia BPF maps via a "signature-by-reference" scheme. The Monad register carries compact 12-byte references (SigRef, KeyRef, SeqNum, HashPfx). Shield verifies signatures at the network perimeter and strips Monad Hop-by-Hop headers at ingress -- internal kingdom traffic never carries PQC wire overhead.¶
Layer 2 (Application-Level, OPTIONAL): User applications MAY define verification requirements in Sophia application policy dictionaries. After wire-level authentication succeeds, the application reads Wotan per-flow PQC state and matches it against its own policy.¶
Four PQC compliance tiers -- NONE, STANDARD, ENHANCED, and SOVEREIGN -- are signaled via Kingdom Mode bits in the Monad flags byte.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them except as reference to a "work in progress."¶
This Internet-Draft will expire on September 19, 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info/) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 September 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The Unheaded Protocol Foundation [MONAD] defines a 20-byte register carried in an IPv6 Hop-by-Hop extension header [RFC8200]. This register provides per-packet metadata for service mesh operations including tracing, QoS classification, circuit breaking, and deployment ring isolation.¶
As quantum computing advances threaten existing cryptographic assumptions, infrastructure systems MUST prepare for post-quantum cryptographic migration. NIST has finalized five PQC standards: three digital signature algorithms -- FIPS 205 (SLH-DSA) [FIPS205], FIPS 204 (ML-DSA) [FIPS204], and FIPS 206 (FN-DSA) [FIPS206] -- and two key-encapsulation mechanisms -- FIPS 203 (ML-KEM) [FIPS203] and FIPS 207 (HQC) [FIPS207].¶
PQC signature sizes range from 666 bytes (FN-DSA-512) to 49,856 bytes (SLH-DSA-SHAKE-256f), all far exceeding the Monad register's 12-byte value field. This document defines a "signature-by-reference" scheme that stores full PQC signatures and public keys in Sophia BPF maps while carrying compact references in the Monad register. Sophia [SOPHIA] dictionaries provide the BPF map structures for signature and key storage. The scheme is algorithm-agnostic -- the same 12-byte wire layout supports all three signature standards.¶
This approach provides:¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The PQC authentication scheme operates in four phases:¶
Phase 1 - Key and Signature Provisioning:¶
The control plane generates SLH-DSA key pairs and pre-computes signatures over expected pseudo-headers. Full signatures and public keys are loaded into Sophia BPF maps. SigRef and KeyRef indices are assigned.¶
Phase 2 - Packet Marking:¶
When a packet enters the Unheaded network at Shield ingress, the Monad register's value field is populated with the SigRef, KeyRef, SeqNum, and HashPfx corresponding to the flow's authentication context. The S (Signed) flag in byte 0x01 is set to 1.¶
Phase 3 - Wire-Level Verification (Layer 1):¶
At the Shield ingress from an untrusted network, the eBPF program at XDP reads the SigRef and KeyRef from the Monad register, retrieves the full signature and public key from Sophia maps, and either:¶
Upon successful verification, Shield strips the Monad HbH extension header. The verification result is persisted in Wotan per-flow PQC state (Section 12). Internal kingdom traffic proceeds without PQC wire overhead.¶
Phase 4 - Application-Level Policy (Layer 2, OPTIONAL):¶
After Shield ingress strips Monad headers and forwards the packet into the kingdom, user applications MAY perform a second verification pass. The application reads the flow's PQC state from Wotan memory (algo_id, key_epoch, verified status, key fingerprint) and matches it against requirements defined in a Sophia application policy dictionary.¶
If the flow's PQC state does not satisfy the application's policy (e.g., algorithm too weak, key too old, fingerprint not pinned), the application MAY reject the flow at the application layer. This provides defense-in-depth and enables per-application security posture without modifying the wire protocol.¶
When the S (Signed) flag is set in the Monad flags byte, the 12-byte value region of the Monad register (bytes specific to the flow action and QoS fields as defined in [MONAD]) SHALL be interpreted as follows:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SigRef (24 bits) | KeyRef[23:16] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KeyRef[15:0] (16 bits) |HashPfx(16 bits)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SeqNum (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Field definitions:¶
Note: When PQC compliance tiers are active (K1|K0 != 00), the S flag (bit 3 of the flags byte) is repurposed from its SAMPLED semantics defined in [MONAD] to indicate Signed status. This dual-use is signaled by the Kingdom Mode bits; implementations MUST check the K1|K0 field before interpreting the S flag. The Monad Flags Registry update for this extended semantics is specified in Section 17.2.¶
A new Sophia BPF hash map SHALL be created for PQC signature storage:¶
Map name: sophia_pqc_sigs Key type: uint32 (SigRef, zero-extended from 24 bits) Value type: struct sophia_pqc_sig_entry Max entries: Configurable (RECOMMENDED: 1,048,576) Flags: BPF_F_RDONLY_PROG (data plane read-only) Pinning: /sys/fs/bpf/sophia/pqc_sigs¶
The value structure:¶
struct sophia_pqc_sig_entry {
uint8_t algo_id; /* SLH-DSA parameter set ID */
uint8_t verified; /* 0=pending, 1=valid, 2=invalid */
uint16_t sig_len; /* Signature length in bytes */
uint32_t flow_label; /* Owning flow label */
uint64_t verify_timestamp; /* Nanosecond timestamp of verification */
uint8_t signature[]; /* Variable-length SLH-DSA signature */
};
¶
The algo_id field SHALL use values from the PQC Algorithm Registry (Section 17):¶
SLH-DSA Parameter Sets (FIPS 205 -- hash-based, eBPF-native):¶
| Value | Parameter Set | Sig Size | Security | eBPF? |
|---|---|---|---|---|
| 0x00 | Reserved | N/A | N/A | N/A |
| 0x01 | SLH-DSA-SHA2-128s | 7,856 B | Level 1 | YES |
| 0x02 | SLH-DSA-SHA2-128f | 17,088 B | Level 1 | YES |
| 0x03 | SLH-DSA-SHA2-192s | 16,224 B | Level 3 | YES |
| 0x04 | SLH-DSA-SHA2-192f | 35,664 B | Level 3 | YES |
| 0x05 | SLH-DSA-SHA2-256s | 29,792 B | Level 5 | YES |
| 0x06 | SLH-DSA-SHA2-256f | 49,856 B | Level 5 | YES |
| 0x07 | SLH-DSA-SHAKE-128s | 7,856 B | Level 1 | YES |
| 0x08 | SLH-DSA-SHAKE-128f | 17,088 B | Level 1 | YES |
| 0x09 | SLH-DSA-SHAKE-192s | 16,224 B | Level 3 | YES |
| 0x0A | SLH-DSA-SHAKE-192f | 35,664 B | Level 3 | YES |
| 0x0B | SLH-DSA-SHAKE-256s | 29,792 B | Level 5 | YES |
| 0x0C | SLH-DSA-SHAKE-256f | 49,856 B | Level 5 | YES |
ML-DSA Parameter Sets (FIPS 204 -- lattice-based, eBPF-native):¶
| Value | Parameter Set | Sig Size | Security | eBPF? |
|---|---|---|---|---|
| 0x10 | ML-DSA-44 | 2,420 B | Level 2 | YES |
| 0x11 | ML-DSA-65 | 3,309 B | Level 3 | YES |
| 0x12 | ML-DSA-87 | 4,627 B | Level 5 | YES |
FN-DSA Parameter Sets (FIPS 206 -- lattice-based, userspace verify):¶
| Value | Parameter Set | Sig Size | Security | eBPF? |
|---|---|---|---|---|
| 0x20 | FN-DSA-512 | 666 B | Level 1 | NO* |
| 0x21 | FN-DSA-1024 | 1,280 B | Level 5 | NO* |
*FN-DSA verification uses integer NTT and MAY be implemented in eBPF. However, FN-DSA signing requires IEEE-754 binary64 floating-point (FFT, LDL tree, Gaussian sampling) and MUST NOT execute in eBPF. See Section 15 (Multi-Algorithm Considerations).¶
KEM Algorithm Identifiers (key establishment only, not per-packet):¶
| Value | Algorithm | CT Size | Security | Use |
|---|---|---|---|---|
| 0x80 | ML-KEM-512 | 768 B | Level 1 | Tunnel key |
| 0x81 | ML-KEM-768 | 1,088 B | Level 3 | Tunnel key |
| 0x82 | ML-KEM-1024 | 1,568 B | Level 5 | Tunnel key |
| 0x90 | HQC-128 | 4,497 B | Level 1 | Tunnel key |
| 0x91 | HQC-192 | 9,042 B | Level 3 | Tunnel key |
Reserved Ranges:¶
| Value | Description |
|---|---|
| 0x0D-0x0F | Reserved (SLH-DSA future) |
| 0x13-0x1F | Reserved (ML-DSA future) |
| 0x22-0x7F | Reserved (signature algos) |
| 0x83-0x8F | Reserved (ML-KEM future) |
| 0x92-0xFE | Unassigned |
| 0xFF | Reserved |
The sophia_pqc_sigs map MUST be created with the BPF_F_RDONLY_PROG flag. Data plane eBPF programs (XDP, TC) MUST NOT have write access. Only the control plane (userspace) SHALL write to this map.¶
A new Sophia BPF hash map SHALL be created for PQC public key storage:¶
Map name: sophia_pqc_keys Key type: uint32 (KeyRef, zero-extended from 24 bits) Value type: struct sophia_pqc_key_entry Max entries: Configurable (RECOMMENDED: 65,536) Flags: BPF_F_RDONLY_PROG Pinning: /sys/fs/bpf/sophia/pqc_keys¶
The value structure:¶
struct sophia_pqc_key_entry {
uint8_t algo_id; /* Must match sig entry algo_id */
uint8_t key_epoch; /* Key rotation epoch counter */
uint16_t key_len; /* Public key length in bytes */
uint8_t fingerprint[32]; /* SHA-256 of full public key */
uint8_t public_key[]; /* Variable-length SLH-DSA pubkey */
};
¶
The SLH-DSA signature MUST be computed over a pseudo-header constructed from immutable packet fields. The pseudo-header ensures that the signature binds to a specific flow, destination, and sequence position.¶
The pseudo-header is constructed as follows (52 bytes):¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source IPv6 Address + | (128 bits) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination IPv6 Address + | (128 bits) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Flow Label (20 bits) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Fields:¶
Implementations MUST construct the pseudo-header identically at both the signing and verification endpoints. Any difference in construction will cause verification to fail.¶
Note: The pseudo-header intentionally excludes mutable fields such as hop_count, the Monad flags byte, and the CRC-16 checksum. Including mutable fields would invalidate the signature at each hop.¶
When a packet arrives at an XDP verification point and the S flag is set:¶
If entry exists and verified == 1 (valid):¶
If entry exists and verified == 2 (invalid):¶
If entry does not exist or verified == 0 (pending):¶
When cached verification is not available:¶
The userspace PQC verifier daemon reads from the ring buffer and performs:¶
If verification fails, the control plane MUST:¶
The PQC verifier daemon MUST implement a health check mechanism. If the daemon becomes unresponsive:¶
The verification policy determines packet handling during the asynchronous verification window (typically 1-5 milliseconds for first packet of a new flow).¶
Packets are held until verification completes.¶
Packets are forwarded immediately; verification occurs asynchronously.¶
The verification policy MUST be configurable per trust boundary. Policy is configured out-of-band via the control plane (see Section 10). The compliance tier determines the default policy: SOVEREIGN defaults to PESSIMISTIC; STANDARD and ENHANCED default to OPTIMISTIC.¶
Implementations MUST default to PESSIMISTIC when no explicit policy is configured.¶
Four PQC compliance tiers govern Shield processing behavior. Tiers are signaled via the Kingdom Mode bits (K1|K0) in the Monad flags byte:¶
| K1 | K0 | Tier | Algorithms | Layer 2 | Multi-Algo |
|---|---|---|---|---|---|
| 0 | 0 | NONE | -- | -- | -- |
| 0 | 1 | STANDARD | SLH-DSA only | OFF | NO |
| 1 | 0 | ENHANCED | SLH-DSA+ML-DSA+FN-DSA | OPT | NO |
| 1 | 1 | SOVEREIGN | All three, 2-of-3 | MANDATORY | YES |
Shield performs no PQC processing. Monad S flag is ignored. No Sophia PQC maps are loaded. No Wotan PQC state is allocated. Wire overhead: zero.¶
Use: development, staging, internal microservices behind a trusted perimeter where PQC is not required.¶
Shield verifies Layer 1 using SLH-DSA only. The primary signature standard (FIPS 205) provides the most conservative security posture: hash-based construction with no lattice assumptions, fully eBPF-native verification.¶
Sophia maps loaded: sophia_pqc_sigs, sophia_pqc_keys. Wotan state: basic PQC fields (0x0000FF00-0x0000FF0F). Layer 2: disabled. Default policy: OPTIMISTIC.¶
RECOMMENDED for: standard SaaS deployments requiring baseline post-quantum compliance.¶
Shield verifies Layer 1 using any of the three signature algorithms (SLH-DSA, ML-DSA, FN-DSA). Applications MAY enable Layer 2 Sophia policy dictionaries for per-application verification requirements.¶
Sophia maps loaded: all PQC maps including sophia_pqc_app_policy. Wotan state: full PQC fields (0x0000FF00-0x0000FF27). Layer 2: optional (applications opt in via policy dictionary). Default policy: OPTIMISTIC.¶
RECOMMENDED for: enterprise deployments requiring algorithm flexibility and application-level security policy (SOC2, HIPAA, FedRAMP).¶
Shield verifies Layer 1 using ALL THREE signature algorithms in a 2-of-3 multi-algorithm cross-verification scheme. Layer 2 is MANDATORY -- every application MUST have a Sophia policy dictionary. Pinned key enforcement is REQUIRED.¶
For each incoming packet, Shield:¶
Sophia maps loaded: all PQC maps, plus sophia_pqc_sovereign_sigs for secondary/tertiary signature entries. Wotan state: full PQC fields plus sovereign audit fields. Layer 2: mandatory. Default policy: PESSIMISTIC. Anamnesis: every verification result emits an audit event.¶
RECOMMENDED for: government, defense, classified environments requiring FIPS 140-3 Level 4 compliance and crypto-agility against single-algorithm compromise.¶
Tier changes are effected via the control plane API:¶
Tier downgrades (e.g., SOVEREIGN to STANDARD) MUST emit an Anamnesis WARNING event. Tier upgrades are silent.¶
SLH-DSA key pairs MUST be generated using a CSPRNG conforming to NIST SP 800-90A [SP80090A]. For deployments requiring FIPS 140-3 validation, key generation SHOULD be performed within a validated Hardware Security Module (HSM).¶
Key rotation is signaled via the key_epoch field in the Sophia PQC Public Key Map entry. When a key is rotated:¶
Immediate key revocation is supported via the key_revoke flow action (action ID 0x12). When a key_revoke action is triggered:¶
The Wotan per-flow memory model [WOTAN] provides storage for PQC authentication state:¶
Within each flow's 64KB Wotan address space, the following addresses are reserved for PQC state:¶
Address Size Field 0x0000FF00 4 last_seen_seq (last verified sequence number) 0x0000FF04 1 pqc_verified (0=no, 1=yes, 2=failed) 0x0000FF05 1 pqc_algo_id (SLH-DSA parameter set) 0x0000FF06 1 pqc_key_epoch (current key epoch) 0x0000FF07 1 reserved 0x0000FF08 4 pqc_verify_count (number of verifications) 0x0000FF0C 4 pqc_fail_count (number of failures) 0x0000FF10 8 pqc_key_fp (truncated SHA-256 of public key) 0x0000FF18 8 pqc_verify_ts (verification timestamp, nanos) 0x0000FF20 4 pqc_key_created (key creation epoch seconds) 0x0000FF24 4 pqc_app_policy_id (Layer 2 policy ref, 0=none)¶
The addresses 0x0000FF10-0x0000FF27 support Layer 2 application policy verification (Section 14). pqc_key_fp and pqc_verify_ts are written by Shield at ingress after successful Layer 1 verification. pqc_app_policy_id is written by the application to record which policy was applied (audit trail).¶
These fields persist after Monad header stripping, providing the authoritative PQC state for internal kingdom operations.¶
The SeqNum field provides replay resistance. Wotan stores the last verified sequence number per flow at address 0x0000FF00.¶
For each packet with S flag set:¶
Shield operates as the perimeter gateway between untrusted external networks and the internal kingdom. PQC wire-level authentication is EXCLUSIVELY a perimeter concern. Monad Hop-by-Hop extension headers are stripped at ingress and re-stamped at egress. Internal kingdom traffic carries zero PQC wire overhead.¶
When Shield receives a packet from an untrusted source with the S flag set:¶
If verification succeeds or policy is OPTIMISTIC:¶
When Shield transmits a packet to an external network:¶
Within the kingdom, after Shield ingress header stripping:¶
This design ensures:¶
Layer 2 verification is OPTIONAL. It enables user applications to define and enforce their own PQC authentication requirements independently of the wire-level infrastructure.¶
Applications MAY define a Sophia dictionary containing PQC policy fields. The dictionary is loaded into a Sophia BPF map and consumed by the application at runtime.¶
Map name: sophia_pqc_app_policy Key type: uint32 (application_id) Value type: struct sophia_pqc_policy Max entries: Configurable (RECOMMENDED: 4,096) Flags: BPF_F_RDONLY_PROG Pinning: /sys/fs/bpf/sophia/pqc_app_policy¶
The policy structure:¶
struct sophia_pqc_policy {
uint8_t min_security_level; /* NIST level: 1, 3, or 5 */
uint8_t require_pinned_key; /* 0=no, 1=yes */
uint8_t num_allowed_algos; /* Count of allowed algo_ids */
uint8_t reserved;
uint32_t max_key_age_sec; /* Maximum key epoch age */
uint8_t allowed_algos[12]; /* Up to 12 allowed algo_id vals */
uint8_t pinned_fp[32]; /* Expected key fingerprint */
/* (if require_pinned_key == 1) */
};
¶
Field definitions:¶
When an application performs Layer 2 verification:¶
Layer 2 operates entirely on Wotan per-flow state and Sophia policy dictionaries. It has NO dependency on Monad wire headers (which have been stripped at Shield ingress). This means:¶
Applications define their policy using standard Sophia dictionary syntax. Example enterprise policy:¶
dictionary "enterprise-auth-policy" {
field pqc_min_security_level uint8 = 3;
field pqc_require_pinned_key uint8 = 1;
field pqc_max_key_age_sec uint32 = 86400;
field pqc_allowed_algos uint8[] = [0x03, 0x04, 0x09, 0x0A];
field pqc_pinned_fp bytes32 = 0xa1b2c3...;
}
¶
This policy requires: NIST Level 3 minimum, specific SHA2/SHAKE-192 algorithms only, key rotation within 24 hours, and a pinned key fingerprint. Any flow not meeting ALL requirements is rejected at the application layer, even if Layer 1 wire authentication passed.¶
The inclusion of three distinct signature algorithm families introduces architectural constraints that implementations MUST address.¶
Not all PQC algorithms can execute entirely within the eBPF/XDP verification pipeline. The following matrix governs where verification occurs:¶
| Algorithm | Verify in eBPF? | Sign in eBPF? | Constraint |
|---|---|---|---|
| SLH-DSA | YES | NO | Hash-only, integer |
| ML-DSA | YES | NO | Integer NTT mod q |
| FN-DSA | PARTIAL* | NO | Float in signing |
*FN-DSA verification performs integer NTT modular arithmetic (mod q=12289) plus L2-norm and infinity-norm checks. These operations are integer-only and fit within the BPF verifier's [RFC9669] 1,000,000 instruction budget (~21,000 instructions estimated). However, implementations MAY choose to route FN-DSA verification to userspace via bpf_kfunc upcall for simplicity.¶
FN-DSA signing requires IEEE-754 binary64 floating-point for: FFT expansion of private basis, LDL tree decomposition, and discrete Gaussian sampling. eBPF does not support floating-point operations. FN-DSA signing MUST occur in a dedicated userspace daemon.¶
When FN-DSA is enabled (Tier ENHANCED or SOVEREIGN), a dedicated signing daemon MUST be deployed:¶
When multiple algorithms are available (Tier ENHANCED or SOVEREIGN), the control plane selects the algorithm per flow based on:¶
The selected algo_id is written to the Sophia signature map entry and persisted in Wotan per-flow state. Algorithm selection MUST NOT change mid-flow.¶
In Tier SOVEREIGN, each flow carries signatures from at least two distinct algorithm families. The Sophia signature map entry is extended:¶
struct sophia_pqc_sovereign_entry {
uint8_t primary_algo_id; /* Primary algorithm */
uint8_t secondary_algo_id; /* Secondary (different family) */
uint8_t tertiary_algo_id; /* Tertiary (0x00 if 2-of-3) */
uint8_t consensus; /* Bitfield: b0=pri b1=sec b2=ter */
uint32_t primary_sigref; /* SigRef for primary sig */
uint32_t secondary_sigref; /* SigRef for secondary sig */
uint32_t tertiary_sigref; /* SigRef for tertiary sig */
};
¶
The consensus field tracks which algorithms have verified successfully. When popcount(consensus) >= 2, the packet is authenticated. This ensures that compromise of any single algorithm family does not break authentication.¶
The KEM algorithms (ML-KEM, HQC) are used for key establishment between Shield instances, NOT for per-packet authentication.¶
When two Shield instances establish a PQC-authenticated tunnel:¶
ML-KEM (FIPS 203) is RECOMMENDED as the primary KEM due to its small ciphertext (768-1,568 bytes) and fast performance.¶
HQC (FIPS 207) SHOULD be available as a non-lattice backup. If lattice-based assumptions are compromised (affecting both ML-KEM and ML-DSA), HQC provides code-based diversity.¶
KEM algorithm identifiers use the 0x80-0x9F range in the algo_id registry (Section 17). KEM entries appear in Sophia key maps but do NOT appear in per-packet Monad headers.¶
This document requests IANA to create a new registry: "Unheaded PQC Algorithm Identifiers"¶
Registration Policy: Specification Required [RFC8126]¶
| Value | Description | FIPS | Reference |
|---|---|---|---|
| 0x00 | Reserved | -- | This document |
| 0x01 | SLH-DSA-SHA2-128s | 205 | This document |
| 0x02 | SLH-DSA-SHA2-128f | 205 | This document |
| 0x03 | SLH-DSA-SHA2-192s | 205 | This document |
| 0x04 | SLH-DSA-SHA2-192f | 205 | This document |
| 0x05 | SLH-DSA-SHA2-256s | 205 | This document |
| 0x06 | SLH-DSA-SHA2-256f | 205 | This document |
| 0x07 | SLH-DSA-SHAKE-128s | 205 | This document |
| 0x08 | SLH-DSA-SHAKE-128f | 205 | This document |
| 0x09 | SLH-DSA-SHAKE-192s | 205 | This document |
| 0x0A | SLH-DSA-SHAKE-192f | 205 | This document |
| 0x0B | SLH-DSA-SHAKE-256s | 205 | This document |
| 0x0C | SLH-DSA-SHAKE-256f | 205 | This document |
| 0x0D-0x0F | Reserved (SLH-DSA) | 205 | This document |
| 0x10 | ML-DSA-44 | 204 | This document |
| 0x11 | ML-DSA-65 | 204 | This document |
| 0x12 | ML-DSA-87 | 204 | This document |
| 0x13-0x1F | Reserved (ML-DSA) | 204 | This document |
| 0x20 | FN-DSA-512 | 206 | This document |
| 0x21 | FN-DSA-1024 | 206 | This document |
| 0x22-0x7F | Reserved (sigs) | -- | This document |
| 0x80 | ML-KEM-512 | 203 | This document |
| 0x81 | ML-KEM-768 | 203 | This document |
| 0x82 | ML-KEM-1024 | 203 | This document |
| 0x83-0x8F | Reserved (ML-KEM) | 203 | This document |
| 0x90 | HQC-128 | 207 | This document |
| 0x91 | HQC-192 | 207 | This document |
| 0x92-0xFE | Unassigned | -- | |
| 0xFF | Reserved | -- | This document |
This document updates the Monad Flags Registry to formally define the semantics of the S (Signed) flag (bit 3) when used with PQC authentication:¶
S = 1: The Monad value field contains PQC authentication references as defined in Section 5 of this document.¶
This document registers three new Sophia map types:¶
| Map Type | Name | Reference |
|---|---|---|
| 0x10 | PQC Signatures | This document |
| 0x11 | PQC Public Keys | This document |
| 0x12 | PQC App Policies | This document |
| 0x13 | PQC Sovereign Sigs | This document |
| 0x14 | PQC KEM Keys | This document |
The signature-by-reference scheme relocates the full signature from the wire to kernel-resident BPF maps. The security of this scheme depends on:¶
The SeqNum field in the Monad register provides replay resistance. Without SeqNum, an attacker who captures a legitimate packet could replay it indefinitely, as the SigRef would still reference a valid cached verification result.¶
The SeqNum MUST be included in the signed pseudo-header. The Wotan per-flow last_seen_seq counter MUST be checked at each verification point. Packets with SeqNum less than or equal to last_seen_seq MUST be dropped.¶
Implementations SHOULD use a sliding window (RECOMMENDED: 64 packets) rather than strict monotonic ordering to tolerate minor packet reordering.¶
The 16-bit HashPfx provides a fast integrity check with collision probability of 1/65,536. This is NOT a security mechanism -- it is an optimization to detect accidental SigRef corruption without performing a full map lookup.¶
Deliberate attacks against HashPfx (preimage or collision) are trivial given its 16-bit size. Security depends entirely on SLH-DSA verification, not on HashPfx.¶
The OPTIMISTIC verification policy creates a window of 1-5 milliseconds during which unverified packets may be forwarded. Deployments with strict authentication requirements MUST use the PESSIMISTIC policy.¶
The OPTIMISTIC policy is acceptable when additional authentication mechanisms (e.g., mTLS) are in place and the PQC authentication serves as a defense-in-depth layer.¶
An attacker may attempt to exhaust Sophia map capacity by generating flows with unique SigRef values. Implementations MUST:¶
As noted in [MONAD], the CRC-16/CCITT checksum detects accidental corruption, not deliberate tampering. PQC authentication via SLH-DSA provides tamper detection. The two mechanisms are complementary: CRC-16 catches transmission errors; SLH-DSA catches deliberate modification.¶
SLH-DSA verification timing may vary based on signature content. Implementations MUST use constant-time comparison for HashPfx and fingerprint checks. The asynchronous verification architecture inherently mitigates timing side channels in the data plane, as verification occurs off the packet forwarding path.¶
The choice of SLH-DSA parameter set determines the quantum security level. NIST Level 1 (SLH-DSA-128s) is RECOMMENDED for most deployments as it provides 128-bit security against quantum attacks with the smallest signature size (7,856 bytes).¶
Deployments handling classified or long-term sensitive data SHOULD use Level 3 (SLH-DSA-192s) or Level 5 (SLH-DSA-256s).¶
The header stripping design confines PQC wire-level attack vectors to the Shield perimeter. This fundamentally limits the blast radius of several attack classes:¶
However, header stripping does NOT mitigate:¶
The dual-layer model provides defense-in-depth:¶
FN-DSA signing requires IEEE-754 binary64 floating-point operations for FFT expansion, LDL tree decomposition, and discrete Gaussian sampling. The "Do Not Disturb a Sleeping Falcon" paper (Eurocrypt 2025) demonstrates that timing variations in these operations can leak private key bits after approximately 2^26 observed signatures.¶
Mitigations:¶
Header stripping does NOT mitigate this finding -- the signing daemon is internal to the kingdom.¶
When FN-DSA verification is routed to userspace via bpf_kfunc upcall, a time-of-check-to-time-of-use (TOCTOU) window exists between eBPF verification and application consumption.¶
Mitigations:¶
Header stripping partially mitigates this -- the TOCTOU window exists only at the Shield perimeter.¶
With three signature algorithm families, an attacker may attempt to force use of a weaker or compromised algorithm by manipulating the algo_id field in the Monad register.¶
Mitigations:¶
Header stripping mitigates this at the perimeter -- algo_id manipulation is only possible from external sources.¶
FN-DSA signing requires approximately 40,448 bits of randomness per signature (79 bits x 512 coefficients). Insufficient entropy in the discrete Gaussian sampling process can cause signatures to leak private key information.¶
Mitigations:¶
Each compliance tier establishes distinct security guarantees:¶
Tier downgrades MUST be treated as security events. A downgrade from SOVEREIGN to STANDARD removes multi-algorithm protection.¶
Cross-algorithm comparison for deployment planning:¶
| Requirement | Recommended Algo | Sig Size | Verify Time | Tier |
|---|---|---|---|---|
| Most conservative | SLH-DSA-SHA2-128s | 7,856 B | ~2ms | STANDARD |
| Fast verification | ML-DSA-44 | 2,420 B | ~0.1ms | ENHANCED |
| Minimum bandwidth | FN-DSA-512 | 666 B | ~0.2ms | ENHANCED |
| High security (hash) | SLH-DSA-SHA2-256s | 29,792 B | ~5ms | STANDARD |
| High security (lattice) | ML-DSA-87 | 4,627 B | ~0.3ms | ENHANCED |
| Government / CNSA 2.0 | SLH-DSA-SHA2-192s+ | 16,224 B | ~3ms | SOVEREIGN |
| Maximum assurance | 2-of-3 (all algos) | varies | ~5-7ms | SOVEREIGN |
Algorithm family trade-offs:¶
SLH-DSA (FIPS 205): Most conservative. Hash-based -- no lattice assumptions. Largest signatures but simplest trust model. Fully eBPF-native. RECOMMENDED for Tier STANDARD.¶
ML-DSA (FIPS 204): Best performance/size ratio. Lattice-based with integer NTT. Fully eBPF-native. If lattice assumptions hold, this is the optimal choice for high-throughput deployments.¶
FN-DSA (FIPS 206): Smallest signatures (666-1,280B). Lattice-based with floating-point signing. Requires userspace signing daemon. Best for bandwidth-constrained links. Carries additional side-channel risk (see Section 18.11).¶
For the signature-by-reference scheme, signature size impacts Sophia map memory, not wire overhead. All algorithms use the same 12-byte Monad value layout.¶
Estimated per-packet overhead at XDP:¶
| Operation | Time | Notes |
|---|---|---|
| Sophia map lookup | 50-100ns | Hash map, kernel memory |
| Cached verification read | ~10ns | Single byte read |
| HashPfx comparison | ~5ns | 2-byte constant-time |
| SeqNum Wotan read | ~50ns | bpf_wotan_read |
| SeqNum Wotan CAS | ~100ns | bpf_wotan_cas |
| Total fast path | ~215-265ns | Per packet, cached |
First-packet slow path (async, one-time per flow):¶
| Operation | Time | Notes |
|---|---|---|
| Ring buffer write | ~200ns | Zero-copy to userspace |
| SLH-DSA verification | 0.5-5ms | Parameter set dependent |
| Map update with result | ~100ns | Control plane write |
| Total slow path | ~1-5ms | One-time per flow |
Memory overhead per concurrent flow (SLH-DSA-SHA2-128s):¶
| Component | Size per flow | 100K flows | 1M flows |
|---|---|---|---|
| Signature entry | ~8 KB | ~800 MB | ~8 GB |
| Key entry | ~100 B | ~10 MB | ~100 MB |
| Wotan PQC state | 16 B | ~1.6 MB | ~16 MB |
| Total | ~8.1 KB | ~812 MB | ~8.1 GB |
(To be provided in a future revision with complete SLH-DSA signing and verification examples using the pseudo-header format defined in Section 7.)¶